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This  Interlsi  Report  describes  progress  during  the  first  ynsr  of  research 
and  development  on  a  program  verification  system  supporting  the  design,  develop 
ment,  and  formal  verification  of  programs  written  In  JOVI AL-J73-I .  The  work 
reported  here  represents  an  outgrowth  and  continuation  of  earlier  efforts 
concerned  with  JOV1AL-J3  and  JOVI AL-J3( JOCIT  version) . 


Detailed  descriptions  are  presented  of  progress  and  future  plans  In  the 
following  aroast  (Cont'd  on  reverse) 
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a.  Analysis  of  tha  JOVIAL-J73/I  language  with  raspact  to  verifiability, 
leading  to  formal  definitions  of  its  syntax  and  semantics,  and  to  tha  onhance- 
aant  of  tha  language  by  aaaartlon  constructs  for  the  purposes  of  apaclf icatioa 
and  verification; 

b.  Tha  organisation,  technical  development,  and  Implementation  of  portions 
of  tha  JOVIAL  Verifier  -  in  particular,  of  a  verification  condition  generator 
and  deduct lva  sybsy stems; 

c.  The  selection,  analysis,  and  verification  of  two  real  software  aye t sms 
of  significant  alsa  and  complexity,  critical  parta  of  which  will  be  imp lament ad 
in  J73/I  and  which  la  hoped  to  be  verified  by  aeana  of  tha  JOVIAL  Verifier. 

\ 

Tha  report  contains  two  appendices,  comprising  a  formal  graamar  (in 
modified  gNP  form)  for  J73/I,  and  a  detailed  mathematical  axioms fixation  of  tha 
semantics  of  floating  point  arithmetic  for  the  language. 
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I  INTRODUCTION 


This  report  describes  progress  aide  during  the  period  froa  IN 
Noveaber  1977  through  31  Deceaber  1978  in  developing  an  effective  systea 
for  use  in  developing  and  aalntalnlng  foraally  verified  JOVIAL  prograas 
of  significant  size  and  coaplexlty.  taring  this  period  we  have: 

*  Coapleted  a  prellalnary  analysis  of  the  iapact  of 
verification  concerns  on  the  JOVIAL  language. 

a  Invented  techniques  for  deterainlng  the  effects  of 
increaental  changes  to  functions,  procedures,  types,  and 
certain  specifications. 

*  Developed  certain  useful  deduction  aechanisas,  a  parser- 
generator,  and  the  aost  laportant  parts  of  a  verification 
condition  generator. 

•  Carefully  selected  two  real  systeas,  critical  parts  of 
vftlch  will  be  verified  using  the  JOVIAL  verifier. 

•  Foraul ated  a  coaprehenslve  plan  for  the  future  developaent 
of  the  JOVIAL  verifier  and  for  verifying  certain  allestone 
exaapl  es. 

Each  of  these  aohleveaents  is  an  laportant  step  in  attaining  our  overall 
goal  of  producing  an  effective  verifier  for  JOVIAL  prograas,  and  each 
will  be  explicated  in  subsequent  sections. 

Over  the  last  few  years,  we  have  gradually  aovsd  away  froa 
verifying  wbitrary  JOVIAL  prograas,  especially  those  written  without 
a'  ion  to  foraal  verification  concern v  taring  that  tlae,  we,  as 
wet*  as  other  researohers  in  prograa  verification,  have  ooae  to 
appreciate  the  laportance  of  clean  prograa  structuring  in  asking  foraal 
verification  practical.  Nlthout  a  sound  aethodology  for  software  design 
and  iapleaentatlon  it  is  difficult,  if  not  actually  laposslble,  even  to 
express  adequate  foraal  specifications  (assertions)  with  respeot  to 
ttiloh  correctness  is  to  be  proved.  The  near  laposslblLity  of  proving 
"correctness"  for  large,  already  existing  prograas,  especially  those 


written  without  attention  to  abstraction,  has  been  often  remarked.  He 
have  therefore  turned  our  attention  to  programs  developed  ao cord Inc  to 
sound  methodological  principles  and  expressed  In  tens  of  wall* 
structured  language  constructs.  The  design  and  foraal  specification  of 
JOVIAL  progress  will  be  done  according  to  the  SRI  Hierarchical 
Development  Methodology  [22]  (henceforth  oalled  HDH).  The  reaultlng 
progress  will  tend  to  be  well  structured,  understandable,  easily 
maintainable,  and  demonstrably  consistent  with  their  specifications. 

Experience  further  Indicates  that  the  presence  or  absenoe  of 
certain  progressing  language  features  also  affects  all  these  deslreble 
properties.  Therefore,  we  performed  s  careful  analysis  of  eaoh 
construct  In  the  JOVIAL  language,  and  oonoluded  that  nearly  all  JOVIAL 
constructs  satisfy  the  requirements  of  formal  verification.  He  are 
pleased  that  only  a  few  restrictions  are  needed  to  significantly  enhance 
verifiability  for  programs  In  this  language. 

Even  though  methodological  concerns  are  addressed  and  suitable 
restrictions  are  plaoed  on  the  JOVIAL  language,  the  verification 
activity  Is  too  tedious  and  ciabersome  to  do  by  hand.  Naohlne 
assistance  Is  needed.  As  a  result  several  program  verification  systems 
have  been  developed  [e.g.,  15,6,9,10,12,17,20,  and  28].  These  systems 
oan  be  viewed  as  consisting  of  three  main  components— a  parser  for 
parsing  programs  and  their  specifications;  a  verification  oondltlon 
generator  for  producing  logical  formulas  (oalled  verification 
conditions)  that.  If  proved,  establish  that  a  program  satisfies  its 
sped  float! ons;  and  a  proof  system  for  proving  verification  conditions. 
Our  planned  system  will  also  include  these  functional  components,  eaoh 
attuned  to  the  JQVIAL-J73/I  programming  language  [1*,l8].  Hereafter 
when  the  term  "JOVIAL"  Is  used  in  this  report  the  Level -I  subset  of 
JOVIAL-J73  should  be  understood. 

In  our  verifier,  as  in  previous  ones,  the  most  oomplex  and  least 
understood  of  these  three  components  Is  the  proof  system.  The  major 
Issue  Is  the  tradeoff  between  generality  and  effioienoy,  which  we  are 

*  References  are  listed  following  Section  VI. 
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addressing  by  following  two  ooaplea  antary  lines  of  research.  The  first 
effort  Is  the  developaent  of  the  Boyer-Moore  theorea  prover  [1,5], 
whloh  is  Intended  for  efficient  general  use.  This  theorea  prover  Is 
based  on  the  theory  of  recursive  functions,  Is  axloaat lcally  extendable, 
and  is  tailored  to  proving  properties  of  prograas  in  the  sense  that  It 
Is  easy  to  aodel  (in  the  Boyer-Hoore  theory)  the  Inductively  constructed 
objects  (e.g.,  Integers  and  sequences)  underlying  the  seaantlcs  of 
prograas.  An  Inescapable  fact  confronting  any  such  theorea  prover  Is 
that,  for  any  branch  of  aatheaatlcs  that  Includes  Inductively  defined 
conoepts,  there  exists  no  algorltha  capable  of  deciding  every  question 
that  can  be  raised.  Thus,  we  are  also  developing  fast,  special-purpose 
theorea  provers  for  certain  specialized  doaalns — e.g.,  for  various 
subclasses  of  Presburger  arlthaetlc  [25,26].  We  feel  that  the  aarrlage 
of  these  two  approaches  to  proving  theoreas  will  give  our  proof  systea  a 
unique  and  powerful  deductive  capability. 

Other  laportant  innovations  In  our  planned  systea  are  its  support 
of  a  foraal  developaent  net hod o logy  and  its  ability  to  deteralne  the 
effects  of  increaental  changes.  As  an  Illustration  of  the  latter 
problsa,  consider  the  task  of  developing  a  foraal ly  verified  operating 
systea.  A  good  strategy  is  first  to  decoapose  the  systea  into  its 
functional  parts,  then  to  design  and  verify  each  part  separately.  The 
file  systea,  for  exaaple,  can  be  broken  down  into  files  and  directories, 
each  of  whose  design  and  verification  Involves  developing  a  large, 
highly  Interrelated  collection  of  specifications,  prograas,  verification 
conditions,  and  proofs.  Certainly,  nuaerous  revisions— e.g.,  to  correct 
an  error  In  a  prograa  or  to  augaent  or  reforaulate  a  specification  — 
would  be  aede  In  getting  this  ayriad  of  detailed  lnforaatlon  to  fit 
together  properly.  Bach  revision  can  raise  a  variety  of  ooaplex 
questions.  Suppose,  for  exaaple,  that  soae  specifications  and  prograas 
dealing  with  flies  are  changed  to  allow  blocks  of  file  storage  to  be 
scattered  throughout  aeaory.  Instead  of  being  allocated  sequentially  as 
originally  planned.  For  this  exaaple,  eoae  of  the  key  questions  are: 
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*  Do  «ny  previous  proofs  about  flies  renal n  valid? 

*  Does  any  oode  for  directories  need  to  be  recoaplled? 

*  Do  all  established  properties  of  the  file  systaa  still 
hold? 

■  Is  the  rest  of  the  operating  systea  affected?  If  so,  how? 

These  are  the  kinds  of  questions  the  JOVIAL  verifier  will  be  able  to 
answer,  thereby  avoiding  excessive  redoing  of  previous  work  unaffeoted 
by  lncreaental  changes. 

This  report  Is  organized  as  follows.  Section  II  suaaaarlsea  our 
analysis  of  the  JOVIAL  language,  proposing  certain  enhances ants  and 
restrictions  for  purposes  of  foraal  verification.  Section  III  describes 
our  progress  In  developing  the  JOVIAL  verification  systaa.  Section  IV 
outlines  our  overall  technical  plan  for  coapletlng  our  analysis  of  the 
JOVIAL  language,  for  developing  the  JOVIAL  verifier,  and  for  producing 
allestone  exaaples  that  reflect  our  progress.  Finally,  Section  V 
suaaarlzes  our  progress  to  date  and  lndloates  our  plans  for  the  next 
year . 
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II  THE  JOVIAL-J73/I  LANGUAGE 


A.  The  Subset  to  be  Verified 

We  Have  carried  out  an  extensive  review  of  the  Level -I  subset  of 
JOVIAL-J73  as  it  is  described  In  [14]  and  [18].  These  reference 
docuaents  were  used  to  construct  a  formal  BNF  grammar  for  use  by  the 
verification  system.  The  grammar  appears  In  Appendix  A  to  this  report. 
No  subsetting  was  employed  in  its  construction — l.e.,  all  of  the 
syntactic  features  described  In  [14]  were  retained  In  our  grammar. 
Consequently,  when  our  parser/ transducer  based  on  this  grammar  has  been 
completed  It  should  be  able  to  parse  any  legal  J73/I  program  Into  an 
internal  form  acceptable  to  our  verification  condition  generator  (VCG) 
described  below.  In  fact,  our  grammar  also  provides  for  assertion 
constructs  (see  Section  11 -C )  needed  specially  for  verification.  Thus, 
this  grammar  Is  actually  an  extension  to  standard  J73/I. 

The  semantics  of  J73/I.  however,  posed  a  more  difficult  set  of 
questions  for  verification.  One  reason  for  this  is  that  they  are 
defined  only  informally  by  the  reference  language  documentation  [18]. 
Wherever  any  reasonable  doubt  occurred  as  to  the  intended  semantics,  we 
wrote  sample  J73/I  programs  to  resolve  such  possible  ambiguities.  In 
all,  several  dozen  such  small  programs  were  compiled  and  executed  on  our 
DGC-10  computer,  in  addition  to  a  good  many  more  that  were  tested 
earlier  In  the  effort  simply  to  gain  experience  and  familiarity  with  the 
language.  A  number  of  these  programs  were  concerned  with  numeric 
semantics,  leading  to  an  axlomat lzat Ion  that  appears  in  Appendix  B. 
Perhaps  the  greatest  concerns  were  occasioned  by  the  mechanics  of 
passing  input-  and  output-parametera,  the  side  effects  on  global 
variables,  the  Initialization  of  formal  parameters,  and  the  handling  of 
name  scopes  in  procedures.  Such  concerns  were  resolved  by  the 
aforementioned  sample  programs  In  conjwotlon  with  careful  attention  to 
the  documentation. 
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The  conclusion  of  this  analysis  of  JOVIAL  syntax  and  seaantlos  was 
that  with  the  exception  of  the  few  excluded  constructs  discussed  below, 
our  verification  systea  could  be  designed  to  handle  all  of  J73/I.  We 
nave  probably  been  conservative  In  this  assessaent,  since  soae  of  the 
excluded  features  could  probably  be  accoaaodated ,  though  with  soae 
difficulty,  and  leading  to  greatly  Increased  tlae  spent  In  deduction  as 
well  as  in  preprocessing. 

B.  Excluded  Constructs 

One  of  the  aost  serious  pitfalls  for  foraal  verification  of 
prograas  lies  In  the  possibilities  afforded  for  "aliasing"  in  soae 
langiages,  Including  JOVIAL.  Aliasing  occurs  whenever  there  are  two  or 
aore  pointers  to  the  saae  data  ltea  in  physical  aeaory.  Assignments  to 
any  one  of  these  pointers  will  then  result  in  aodlflcation  of  the  object 
pointed  to  by  all  the  other  pointers.  Moreover,  In  J73/I  such 
assignments  need  not  be  aade  through  explicit  asslgnoent,  but  can  also 
occur  through  the  passing  of  actual  output  parameters  by  reference.  The 
difficulty  such  aliasing  poses  for  verification  is  that  the  VCs 
generated  for  such  prograas  aust  then  contain  large  conditional 
expressions  over  all  pointer  variables  that  aay  potentially  be  aliased 
with  the  one  actually  subjected  to  asslgnaent.  The  detection  of  which 
pointers  potentially  share  structure  aay  require  subtle  analysis 
(perhaps  diring  a  preprocess  phase  of  verification  condition 
generation),  and  the  actual  proof  of  the  large  resulting  VCs  can  be 
extremely  tedious.  Whether  two  pointers  are  actually  (as  opposed  to 
potentially)  aliased  aay  depend  on  the  run-tlae  environment  and, 
therefore,  require  even  aore  subtle  proof  techniques. 

A  particularly  troublesome  fora  of  aliasing  can  arise  through  the 
use  of  table  and  block  overlays.  This  is  because  the  overlapping  of 
aeaory  references  Is  thereby  aade  dependent  on  the  calculation  of 
absolute  aeaory  locations,  soaethlng  that  should  be  avoided  at  all  costs 
in  formal  verification. 


6 


ic  la,  therefore,  considered  necessary  to  exolude  fro* 
consideration,  at  least  Initially,  any  features  of  JOVIAL  that  could 
lead  to  aliasing.  The  Impact  of  this  restriction  on  the  flexibility  and 
utility  of  JOVIAL  programs  is  not  entirely  clear  at  this  point.  There 
will  certainly  be  an  Increase  in  the  data  storage  requirements  for  such 
progress,  e.g..  If  overlays  are  prohibited.  However,  we  are  atteaptlng 
to  find  ways  around  this  problea,  and  it  aay  not  be  necessary  to  forbid 
all  Kinds  of  aliasing,  but  merely  to  "tame"  It. 


Another  troublesome  aspect  of  real  programming  languages  lies  In 
the  possibility  of  generating  hidden  side  effects  through  the  evaluation 
of  expressions,  particularly  In  function  oalls.  The  insidious  nature  of 
such  effects  aay  be  well  appreciated  through  the  observation  that,  too 
often,  overly  "clever”  programmers  will  make  deliberate  use  of  such  side 
effects— e .g . ,  In  function  cslls  occurring  within  Boolean  tests — without 
adequately  appreciating  that  an  optimising  compiler  aay  change  the  order 
of  evaluation  of  subexpressions  and  thereby  destroy  or  distort  the 
intended  effect.  It  is  laposslble  to  account  adequately  for  such 
compiler  optimisation  effects  without  a  formal  specification  of  iffiat  the 
compiler  might  do.  (Note,  for  example,  that  In  several  places  the 
reference  document  (IS]  states  that  the  order  of  evaluation  of  certain 
expressions  must  be  regarded  as  undefined.)  In  view  of  such 
uncertainties,  we  have  had  to  restrict  the  use  of  (expression  level) 
function  calls  to  functions  without  side  effects  on  global  variables. 
Fortunstely,  this  does  not  rule  out  procedures  (callable  at  statement 
level).  These  are  allowed  to  have  side  effects.  Moreover,  In  the 
absence  of  aliasing,  the  presence  of  side  effects  in  formal  functional 
procedures  can  be  detected  by  straightforward  analysis  of  the  function 
body.  We  might  therefore  even  permit  such  procedures  to  be  submitted  to 
the  verifier,  but  place  the  burden  of  guaranteeing  the  absence  of  any 
hidden  side  effects  on  the  programmer,  rather  than  on  the  verifier.  On 
the  whole,  however.  It  Is  probably  the  better  course  simply  to  rule  out 
assignments  to  external  variables  within  a  function  body,  whether  by 
explicit  assignment  or  by  cslls  to  procedures  invoking  side  effects. 
This  restriction  on  the  programming  style  of  the  JOVIAL  progremmer  Is 


not  a  S4W«  on*.  W*  regard  It  a  Impact  on  tn*  prograaaer  as  alnlaal . 
Moreover,  acat  prograaaer s  would  pro D ably  agr«*  tnat  th*  raatrlctlon  la 
good  prograaalng  praotlo*  and  that  It  facilitates  roadability, 
cheokabll ity ,  and  aalntalnabll lty  of  th*  resulting  cod*. 

A  final  exclusion  concerns  the  DEFINE  construct.  This  la 
essentially  a  source  aacrc  facility  that  permits  th*  oreatlon  and 
acdlflcatlcn  of  source  code  by  the  substitution  of  paraaatriaed 

character  strings.  The  verification  of  J73  progress  that  use  the  DEFINE 
feature  would  require  th*  deductive  aystea  to  be  able  to  deal  with 
character  string  substitutions  (often  through  several  levels,  as  tdiere  a 
DEFINE  call  uses  paraaeters  Involving  a  "defined"  naae,  or  a  DEFINE 
string  contains  such  a  naae).  Fortunately,  one  can  slaply  apply  th* 

verification  systea  to  the  expanded  cod*.  The  ILIST  DEFINE  directive  of 
J73/1  provides  the  capability  for  perforalng  this  aacrc-ex pension,  and 
w*  plan  to  have  the  verifier  perfera  Its  analyses  on  the  expanded  ood* 
frea  tfilch  all  DEFINE*  nave  been  raaeved.  Not*  that  this  is  not  really 
a  restriction  on  the  source  language,  but  rather  a  question  of  the 
philosophy  of  verification.  Since  it  Is  the  expanded  code  that  gats 
coaplled,  verification  of  th*  expended  code  is  actually  a  sounder 
approach  tnan  verification  of  the  source  cod*.  If  It  were  feasible  to 
verify  coaplled  aachine  cod*  (we  believe  It  la  notl)  it  would  be 

sounder  tc  dc  sc  than  to  verify  source  code,  sloe*  th*  coapller 

seaantlcs  would  then  net  coae  Into  question.  Hacro-ex pension,  nowever, 
is  a  small  step  in  the  saae  direction,  and  we  believe  that  aacro- 
ex pended  cod*  can  be  verified. 

c.  Banana— «fca  lar.  YgrlfUaLlan 

Certain  additions  tc  the  JOVIAL  syntax  aust  be  provided  for  th* 
purpose  of  verification.  We  refer  here  to  the  entry-,  exit-,  and 
lnteraedlate-assertlons  required  In  the  Floyd-Hoar*  approaoh,  and  also 
tc  specifications  (In  the  style  of  HDH)  ffcr  hierarchical  verification. 
We  chose  to  add  lnteraedlate  assertions  to  th*  fonasl  syntax  by 
Including  an  additional  production  <assert_stat>  under  the  nonteralnal 
<slspl*_stat>  (which  la,  ultieately,  one  of  the  fores  of  th*  nonteralnal 
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<stateaent>;  see  productions  /*2 98*/,  /#3 12#/,  snd  /•32k#/  in  the 
grsaaar  shown  in  Appendix  A.) 

Ths  stateaent  type  <assert_atat>  ( see  Appendix  A,  production 
/•378*/)  osn  talcs  any  one  of  ths  thrss  fores: 

ASSERT  fcrauls 
ASSUME  fcrauls 
PROVE  forauls  • 

Tne  alnor  ssaantlc  diffsrencss  aacng  these  three  kinds  of  assertions  are 
discussed  In  Section  III-B-3-  The  first,  type,  ASSERT  foraula,  is  the 
usual  ea bedded  Floyd  assertion;  the  other  two  types  are  variants  useful 
for  providing  flexibility  In  the  foras  of  the  thecreas  produced  by  the 
verification  condition  generator  (VCG).  These  stateaents  are  Intended 
only  for  use  by  the  VCG  and  are  supposed  to  be  ignored  by  the  actual 
J73/1  coapller.  J73/I  prograas  legal  by  our  graaaar  aay  contain  such 
assertion  stateaents  wherever  a  stateaent  is  legal  in  standard  J73/I. 
For  such  prograas  to  be  accepted  by  a  standard  J73/I  coapller,  the 
assertions  aust,  of  ocurse,  be  ellalnated  or  aade  transparent  once  the 
prograa  has  been  verified.  One  possibility  Is  to  have  a  preprocessor 
transfora  all  such  assertions  into  coaaents  before  subaittlng  the 
prograa  to  the  coapller. 

In  addition.  It  was  convenient  to  peralt  inductive  assertions  tc  be 
eabedded  directly  in  iterative  stateaents,  i.e.,  any  of  the  J73/1 
loop.stateaent  foras.  This  was  accoaplished  by  allowing  an  optional 
clause  of  the  type  assert.stat  wltnin  both  wnile_stat  and  for_stat  (see 
Appendix  A,  /•363*/  and  /#36A*/).  Any  J73/I  iterative  stateaent  lacking 
such  an  Inductive  assertion  is  presently  transduced  with  a  vacuous 
assertion  clause  (ASSERT  T)  fbr  use  by  the  VCG.  Thus,  it  is  also 
possible  for  the  hiaaan  verifier  to  Insert  loop  assertions  aanually  after 
parsing/ transduct  ion  ir  he  wishes.  However,  this  possibility  should  be 
considered  aerely  as  an  interia  convenience  for  use  while  the  systea  Is 
under  develcpaent.  In  our  coapleted  verifier  the  systea  will  detect  the 
absence  of  any  such  essential  assertions  and  will  insist  that  the  user 
provide  thea  In  the  source  code  before  transduction  and  the  generation 
of  verification  conditions  can  be  coapleted. 
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Procedure-level  Input/output  specifications  have  been  provided  by 
allowing  optional  entry/axlt  assertions  (as  declarations)  within  the 
body  of  a  procedure  declaration.  See  Appendix  A,  ltees  /*263*/, 
/•2 96*/ ,  /•301*/,  and  /•3T1*/.  The  syntax  for  the  added  declaration 

type  <assert_decl>  Is: 

ASSERTIN  foreula 

ASSERTOUT  foreula 

The  key  words  ASSERTIN  and  ASSERTOUT  were  chosen  so  as  not  to  confllot 
with  the  JOVIAL  reserved  words  ENTRY  and  EXIT,  which  would  otherwise 
have  been  the  aost  natural  teres  to  use  for  the  entry  and  exit 
assertions  associated  with  procedures.  These  assertion  declarations 
fora  part  of  the  aechanlsa  for  hierarchical  verification  of  progress 
that  contain  procedure  calls.  The  declarations  are  processed  only  by 
the  VCG  sub  functions  concerned  with  procedures.  The  reason  for 
Including  ASSERTIN  and  ASSERTOUT  declarations  In  addition  to  the  above 
ASSERT  statements  is  to  facilitate  structured  proofs  of  prograa 
correctness.  This  approach  allows  the  verification  of  the  body  of  a 
formal  procedure  to  be  decoupled  from  any  calls  to  that  procedure.  The 
formal  procedure  need  then  be  verified  only  onoe  (corresponding  to  Its 
declaration)  regardless  of  now  often  It  aay  be  Invoked  In  a  prograa. 
More  detailed  discussions  of  this  iaportant  point  aay  be  found  In  [9] 
and  [10]. 

Future  additions  of  slallar  nature  aay  be  required  to  aoooaaodate 
HDH  specifications,  al  though  it  is  also  possible  to  handle  such 
specifications  apart  fro  a  the  JOVIAL  laplaaentatlon  itself.  JOVIAL 
progress  would  then  first  be  specified  (e.g..  In  the  HDN  language 
SPECIAL)  through  a  succession  of  HDH  modules  at  several  levels  of 
abstraction.  However,  the  SPECIAL  language  would  then  need  to  be 
augmented  to  accoaaodate  the  JOVIAL  control  constructs  required  In  the 
laplaaentatlon  of  these  nodules. 


Ill  THE  JOVIAL  VERIFIER 


The  gross  architecture  of  the  JOVIAL  verifier  is  shown  in  Figure 
III— 1  -  The  hue an  designer/verifier  coaaunicates  with  the  assistant, 
which  Invokes  the  translator  for  parsing  and  type  checking,  the 
verification  condition  generator  for  producing  verification  conditions, 
and  the  proof  systea  for  atteaptlng  a  aatheaat leal  proof  of  oertaln 
formulas.  This  section  attempts  to  describe  the  main  functional 
characteristics  of  each  of  these  coaponents,  its  general  organization, 
the  progress  aade  in  its  developaent,  and  what  reoains  to  be  done. 
Specific  technical  details  are  generally  oaltted  if  they  have  already 
been  described  in  the  technical  literature.  Such  relevant  docuaents  are 
cited  in  the  text. 

An  additional  fhot  that  should  be  mentioned  is  that  soae  systea 
coaponents  (especially  the  proof  systea)  have  been  supported  in  part  by 
other  projeots  in  the  Coaputer  Science  Laboratory.  It  has  becoae 
apparent  that  this  relationship  has  been  mutually  beneficial  for  all  the 
projeots  Involved. 

a.  TrgnaiitiQr 

The  JOVIAL  verifier  aust  contain  two  translators — one  for  SPECIAL 
[2*]  (the  formal  specification  language  to  be  used),  and  one  for  the 
dialect  of  JOVIAL  to  be  supported.  Each  translator  will  consist  of  a 

parser,  generated  by  the  INTERPG  parser  generator  [27],  and  a  type 

checker.  Ihelr  output  will  be  a  new  representation  of  the  source  code 
appropriate  for  Internal  manipulation  by  the  verifier. 

An  important  consideration  in  the  design  of  this  internal 
representation  is  that  it  should  be  able  to  accoaaodate  any  JOVIAL 

dlaleot,  as  well  as  other  source  languages  such  as  DOD/1.  Attaining 

this  goal  is  important  because  a  XVI AL  verifier  based  on  such  an 


internal  fora  can  ba  fairly  dlreotly  converted  to  support  an  entirely 
different  souroe  language.  The  translator  aust  be  rewritten,  but  all 
tbe  rest  of  the  verifier  should  reaaln  essentially  unchanged.  Our 
Initial  out  at  designing  such  an  Internal  fora  adhered  to  the  following 
desiderata: 

*  Tne  Internal  fora  aust  have  a  slaple  and  well  defined 
seaantlcs. 

*  Tne  verification  conditions  generated  by  the  verification 
condition  generator  (operating  on  the  Internal  fora 
translated  froa  soae  source  language  prograa)  should  be 
equivalent  to  those  that  would  be  generated  by  a 
verification  condition  generator  operating  dlreotly  on  the 
source  language  prograa. 

*  The  Internal  fora  should  be  alnlaal ,  having  only  constructs 
necessary  for  the  attalnaent  of  the  other  goals. 

*  The  Internal  fora  should  be  applicable  to  a  wide  variety  of 
source  languages,  but  should  not  be  unnecessarily 
predisposed  toward  any  single  source  language  or  group  of 
souroe  languages. 

*  It  aust  be  possible  to  associate  stateaents  and  constructs 
In  the  Internal  fora  with  the  stateaents  and  constructs  in 
the  source  language  prograa  froa  tfiich  they  were  derived. 

Certain  slapllfylng  restrictions  were  aade  In  order  to  expedite  the 
developaent  of  this  prellalnary  version.  These  restrictions  will  be 
relaxed  In  later  versions  of  the  Internal  fora.  Presently,  the 
restrictions  are  as  follows: 

*  Only  sequential  progress  are  considered.  We  attempted  to 
avoid  doing  anything  that  would  aake  parallel  prograas 
difficult  to  handle,  but  we  did  not  investigate  the 

probleas  of  handling  concurrency  on  the  Internal  fora. 

• 

*  The  source  languages  considered  are  JOVIAL,  MODULA,  PASCAL, 
and  DOD/1  (actually  verifiable  subsets  of  these  languages). 

Again  we  tried  to  avoid  doing  anything  that  would  preclude 
handling  of  other  languages  but  we  did  not  explicitly 
consider  any  other  languages. 

■  Paraaeter  aliasing  is  not  peraltted . 

The  internal  fora  Is  heavily  based  on  the  asseably-language-llfce 
language  developed  by  R.  Boyer  and  J  S.  Moore  as  part  of  their  foraal 
definition  of  HDM  [A].  The  first  out  at  the  Internal  fora  graaaar  la 
given  below: 
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< function  lapleaantatlon> 

( < funo 1 1 on  naae>  (<arg  llat>)  <lnst  aeq>) 

< irg  llat> 

<null  atrinc>  1  <arg>  <arg  llat> 

<lnst  aeq> 

<null  strlng>  I  <lnstruotlon>  <lnst  seq> 

<  Instruction 

< label >  (Instruction 
!  (GO  (label >) 

!  (ASSERT  <up> ) 

!  ( COMMENT  < quo ted  strlng>) 

!  (RETURN  <axp>  (case  list>) 

I  <«p> 

(case  1 1st  > 

<null  strlng>  I  <case>  <oese  list> 

(case> 

(< literal  exp>  <lnat  aeq>) 

<«P> 

<var> 

!  (<functlon  naae>  ((exp  llat>)  <oaae  llat>) 
(exp  llat> 

<null  strlng>  !  <exp>  (exp  llat> 


The  parser/ transducer  serves  to  define  the  aouroe  language  syntax 
(•ore  properly,  the  context-free  portion  of  that  ayntax)  to  the 
verifier.  For  purpoaes  of  prograa  verification  It  nay  he  aasuaed  that 
all  prograa a  will  flrat  be  checked  for  legality  by  an  aotual  J73/1 
coapller  (for  the  Intended  aeohlne).  Hence,  it  la  redmdant  to 
Incorporate  checking  for  the  context-sensitive  ayntax  In  the  front  end 
of  the  verifier.  (In  fact.  It  alght  be  argued  that  the  ayntaotlo 
checkl.tg  carried  out  by  the  parser/ transducer  la  also  redundant. 
However ,  this  checking  la  a  by-product  of  parsing  the  prograa  Into 
Internal  fora,  and  It  certainly  does  no  ham . )  Sxaaples  of  ayntaotlo 
cheoks  not  carried  out  by  our  parser/ tranaduoer  are: 

•  Scope  ohaoklng  of  declaration  before  use  for  naaee  (of 
variables,  procedures,  lteas,  tables,  eto.) 
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*  Type  oheoklng  of  aotual  pro cedar#  parameters  against  the 
corresponding  formal  types 

*  Haiti  pie  definition  of  names  in  s  given  scope 

■  Return  statement  occurring  outside  a  procedure 

*  Multiply -defined  switch  points. 

On  the  other  hand,  checks  of  the  following  illegal  situations 
(among  others  not  listed)  gc&  carried  out  by  our  parser/ transducer: 

*  Misuse  of  a  reserved  JOVIAL  word  as  an  identifier 

*  Output  parameters  in  a  function  call  or  function 
declaration 

*  Appearanoe  of  constructs  at  inappropriate  contexts  (e.g., 
use  of  a  function  call  at  statement  level) 

These  checks  are  made  even  though  the  same  matters  would  be  cheoked  by 
the  actual  JOVIAL  compiler. 

b.  verif  lost  ion  foafliuaa  fitruratar 

1.  General 

The  purpose  of  the  verification  condition  generator  (VCG)  In  a 
software  verification  system  Is  to  generate  methematioal  formulas  that 
express  conditions  for  consistency  between  a  program  and  Its 
specifications.  These  formulas  are  called  verification  conditions 
(VCs).  Our  VCO  will  operate  on  Internal  representations  of  the  JOVIAL 
programs  to  be  verified.  To  do  Its  Job  properly  the  VCG  must 
Incorporate  knowledge  about  the  semaitlcs  of  the  Input  language  (as 
reflected  In  the  Internal  representation).  The  Internal  representations 
are  produced  by  an  input  parser/transducer  meohanioally  constructed  from 
a  formal  (modified  BNP)  grammar.  A  tentative  grammar  for  J0VIAL-J73/I 
is  shown  in  Appendix  A.  The  combination  of  the  parser/ transducer  with 
the  VCG,  whloh  we  refer  to  as  the  verifier  "front  'bnd”,  is,  in  fact,  a 
verification  condition  camel ler  for  the  actual  source  language  ( J73/I) . 

Our  plan  Is  to  complete  the  present  VCG  implementation 
described  In  the  next  subsection  to  provide  us  (by  the  end  of  this  year) 
with  a  theorem  generator  for  a  prototype  JOVIAL  verifier  capable  of 


verifying  J73/I  progress  that  contain  Halted  procedural  hierarchy. 
This  first-cut  systea  would,  however,  not  incorporate  the  HUM 
aethcdclogy.  Our  final,  delivered  systea  will  eaploy  the  approaoh 
described  in  Section  III-A,  using  secondary  translations  of  the  initial 
Internal  foras,  in  order  to  incorporate  HDM,  and  with  it  data 
abstraction . 

2.  LaUttraal  faraa 

The  internal  foras  produced  by  our  parser/transducer  will  be 
essentially  faithful  representations  (as  parse  tree  structures)  of  the 
input  source  language  program.  There  are  two  slightly  different  ways  in 
which  these  initial  internal  foras  can  be  processed  to  generate 
verification  conditions.  The  direct  approach  is  to  lapleaent  a  VCG  (in 
teras  of  predicate  transformer  functions)  that  operates  dlreotly  on 
these  initial  Internal  foras.  This  is  the  approaoh  that  was  followed  in 
the  preceding  RP6/1  and  RPE/2  projects  for  J0V1AL-J3  [9,10].  In  our 
first  year's  work  under  the  present  prograa  VCG  lapleaentatlon  has  also 
largely  pursued  this  philosophy.  The  second  approaoh  entails  a  two-step 
prooess:  (1)  translating  the  initial  parsed  foras  into  a  low-level, 
asseably-llke  language  (see  Section  11I-A),  and  (2)  la plea anting  either 
a  conventional  VCG  or  a  symbolic  interpreter  for  this  language.  This 
second  approach  is  likely  to  be  siapler  in  the  long  run  and  also  has  the 
advantage  cf  providing  a  acre  uni  fora  aechanlsa  tfiloh  could  be  applied 
to  other  source  languages.  Thus,  the  specialisation  to  a  particular 
source  language  (such  as  JOVIAL-J73/1)  appears  entirely  in  the  internal 
fora  translator,  and  a  single  VCG  aay  be  shared  aaong  several  languages. 
There  is  an  additional  advantage  to  this  approach:  Froa  soae  early 
experlaents  in  verifying  consistency  for  aodules  specified  in  teras  of 
the  HDM  language  SPECIAL  [22],  it  appears  that  this  approaoh  ia  better 
suited  for  interfacing  conventional  verification  with  hierarchical 
scheaes  such  as  HDM.  In  these  experlaents  the  low-level  language  was 
given  operational  definition  by  aeans  of  a  symbol io  Interpreter. 
However,  an  axloa-based  VCG  oould  probably  be  eaployed  in  much  the  saae 
wanner . 


16 


The  implementation  described  In  the  next  subsection  Is  based 
on  the  first  (direct)  approaoh. 


The  lapleaentatlon  described  briefly  here  Is  one  based  on  the 
notion  of  predicate  transforaers  [7].  It  currently  handles  only  a 
subset  of  the  executable  stateaent  types  of  JOVIAL-J73/I.  The  Input 
expected  by  this  VCG  subsystea  la  the  Initial  Internal  fora  of  a  JOVIAL 
prograa  annotated  by  Inductive  assertions  and  provided  with  Input  and 
output  sped float ions  for  any  eabedded  procedure  declarations.  An  Input 
assertion  and  an  output  assertion  for  the  prograa  as  a  whole  are  also 
assuaed  to  have  been  provided.  The  Internal  (loop-cutting)  Inductive 
assertions  are  required  at  each  targeted  labeled  stateaent  and  within 
any  loop  stateaanta  (see  Section  II-C). 


The  VCG  output  Is  a  list  of  VCs,  one  for  each  executable  path 
between  assertion  points.  Each  such  VC  Is  computed  by  "pushing 
baokward"  an  assertion  froa  a  "final"  assertion  point  until  a  prior 
assertion  point  Is  reached.  The  transforaat ion  through  each  type  of 
executable  stateaent  Is  perforaed  by  a  VC  subfunction  that  lapleaents  a 
Hoare  axiom  or  rule  [13]  for  that  particular  stateaent  type. 
Declarations  (of  data  lteas  and  procedures)  are  transparent  to  this 
process  of  predicate  transforaat ion,  but  they  produce  a  side  effect  on 
the  data  base  of  the  VCG  subsystea  that  Is  analogous  to  the  production 
of  the  symbol  table  by  a  conventional  ooapller.  The  whole  process  Is 
ooaplete  when  the  prograa's  Input  assertion  has  been  reached. 


The  aaln  predicate  transroraer  function  is  called  VCS.  The 
subfunotions  referred  to  above  have  naaea  of  the  fora  VCR: IF,  VCR: ASST, 
VCR: ASSERT,  and  the  like,  each  one  designed  to  produce  the  required 
predicate  transforaat Ion  on  Its  second  Input  argument  when  the  stateaent 
being  processed  is  an  lf-stateaent,  assignment  stateaent,  or  assert 
stateaent,  respectively.  The  particular  VCR  subfunction  appropriate  to 
eaoh  stateaent  type  of  JOVIAL  is  automatically  invoked  by  VCS  thrown 
exaalnatlon  of  the  Internal  fora  of  the  stateaent  being  processed.  This 


selection  Is  facilitated  by  tbs  fsot  that  tbs  initial  eleaent  of  saoh 
lntsrnal  fora  is  a  key  word  (e.g.,  WHILE,  If,  FOR,  and  :•)  that  uniquely 
Identifies  the  statement  type. 

As  discussed  in  Section  II-C,  the  aaohlnery  of  verification 
required  the  addition  of  assertion  stataaenta  to  the  JOVIAL  syntax.  In 
fact,  the  assertion  types  ASSERT,  ASSUME,  and  PROVE  are  subauaed  under 
the  nonteralnal  <assert_stat>  (see  Appendix  A).  The  single  assertion* 
type  ASSERT  would  aotually  have  suffioed,  but  It  la  technically 
convenient  to  have  all  three  available.  They  differ  as  to  the  details 
of  the  verification  conditions  (VCs)  they  lnduoe  VCQ  to  produoe.  In 
particular,  with  regard  to  nuaber  and  ooaplexlty.  Roughly  speaking,  the 
differences  are  that  ( 1 )  an  "asserted"  predicate  aust  be  proved  When 
reaohed,  and  It  also  Initiates  a  new  VC  path;  (2)  an  "asauaed"  predicate 
need  not  oe  so  proved,  and  does  not  create  a  new  path,  but  Is  Instead 
coablned  with  prior  predicate  lnforaatlon;  and,  finally,  (3)  "prove" 
predicates  aust  be  proved,  but  they  are  like  "assuaed"  predicates  In  not 
starting  new  paths.  The  use  of  PROVE  In  plaoe  of  ASSERT  for 
lnteraedlate  assertions  will  therefore  result  In  fewer,  but  aore  coaplex 
VCs. 

The  ASSERT  stataaent  is  the  usual  eabedded  Floyd  assertion. 
When  one  Is  encountered  by  VCG  In  soannlng  the  prograa,  VCG  begins  to 
construct  a  logical  foraula  (VC)  with  the  asserted  predicate  aa 
hypothesis.  This  VC  Is  not  coapleted  ixitll  the  next  ASSERT  stateaent  la 
encountered,  at  which  point  (a  aodlf led  fora  of)  this  terminating 
assertion  Is  used  as  the  oonoluslon  for  the  constructed  foraula.  The 
details  of  the  aodlflcatlon  are  determined  by  the  code  Intervening 
between  the  two  assertions.  If  an  ASSUME -type  assertion  appears  between 
the  Initial  and  terminal  ASSERTs,  the  "assuaed"  predicate  would  be 
oonjolned  to  the  hypothesis.  Slnoe  ASSUMEd  predicates  sre  not  subjected 
to  proof  (they  only  appear  In  hypotheses),  the  ASSUME  stateaent  would 
normally  be  used  only  for  initial  assertions  of  a  prograa.  . Howsver ,  it 
night  also  be  used  for  Intermediate  assertlona  that  are  aubjeoted  to 
soae  Independent  check  (e.g.,  run-tine  oheoks  by  ooapl ler -generated 
code ) . 


The  purpose  of  the  PROVE  stst«a«nt  is  to  allow  introduction  of 
an  intermediate  assertion  (vhloh  aust  be  proved  «en  It  Is  reaohed)  but 
whloh  also  ploks  up  all  prior  hypotheses  for  that  path.  This  has  the 
advantage  that  predicates  that  are  true  globally  over  a  program  do  not 
need  to  be  repeated  (as  would  be  the  case  If  ASSERT  were  used  Instead  of 
PROVE). 


A  precise  description  of  the  above  distinctions  In  teras  of 
Hoars  axloas  for  the  three  types  of  assertion  stateaents  appears  in  an 
SRI  report  (11].  The  saae  report  also  contains  foraal  proofs  of 
consistency  between  the  Hoare  axloas  and  a  LISP  lapleaentatlon  (for  a 
auch  slapler  VCC). 


The  types  of  executable  JOVIAL  stateaents  for  which  versions 
of  the  corresponding  VCR  subfunctions  have  been  iapleaented  are: 


■  Assignment  stateaents  (staple  and  aultiple  left  sides) 

*  Conditional  stateaent 

*  Loop  stateaent  (the  "tfille"  fora) 

■  BEGIN. . .END  stateaent  sequences 

*  GOTO  stateaent 

*  Assertion  stateaents  (assert,  assuae,  and  prove) 

*  Procedure  calls  (with  soae  restrictions  on  side  effects) 

*  Faction  calls  (without  side  effects) 

■  STOP  stateaent. 


Of  the  types  listed  above,  the  procedure  call  poses  the 
greatest  difficulties  for  VCG  lapleaentatlon,  and  also  the  worst 
potential  pitfalls  In  "getting  the  seaantlcs  right".  We  have  used  a 
version  of  the  procedure  call  rule  given  for  EUCLID  [16],  with  certain 
aodlfloatlons  necessitated  by  differences  In  the  seaantlcs  of  paraaeter 
passing  for  structured  variables  In  JOVIAL.  The  present  VCG 
lapleaentatlon  (for  procedure  call)  cannot  be  considered  final,  since 
JOVIAL  has  soae  Idlosyncracles  that  probably  have  no  counterparts  in 
other  languages— e.g.,  foraal  output  paraaeters  that  are  not  also  Input 
paraaeters  are  given  a  default  Initialisation  (to  sero)  on  procedure 


Among  the  main  features  of  JOVIAL  that  have  not  been 
aooommodated  as  yet  In  the  present  VCG  Implementation  are  the  following: 

*  Switch  statements 

*  The  for-loop  statement 

*  Return  statements  within  procedures 

*  Intrinsic  functions 

*  Tne  semantics  of  real  machine  arithmetic. 

None  of  these  pose  really  difficult  problems,  except  perhaps 
the  last  item.  Even  there  the  difficult  portion  of  the  Job  has  already 
been  done — viz.,  a  mathematical  axlomatlzation  of  most  of  these 
semantics  (see  Appendix  B) .  The  actual  implementation  of  this 
axlomatlzation  of  floating-point  arithmetic  remains  to  be  oarrled  out. 
The  other  items  above  can  be  handled  by  a  combination  of  modifications 
to  the  VCG  developed  for  J3-J0CIT  [10]  and  the  Judicious  use  of  mappings 
(secondary  transductions  within  the  VCG)  of  these  statement  types  into 
types  already  handl ed--e .g . ,  the  for-loop  statement  can  be  internally 
transduced  into  an  equivalent  while-loop  for  which  the  VCR  subfunction 
exists.  The  intrinsic  functions  and  return  statement  will,  however, 
require  special  handling. 

C.  Proof  System 

Since  an  effective  proof  system  is  essential  to  meohanloal  program 
verification,  considerable  effort  has  been  spent  in  exploring  various 
approaches  to  proving  theorems.  Attention  was  primarily  focused  on  the 
Boyer-Moore  recursive  function  theorem  p rover  [1,5],  on  improving  an 
earlier  implementation  of  Smullyan's  analytic  tableaux  [10],  and 
developing  fast  decision  procedures  for  certain  olasses  of  formulas  that 
frequently  occur  in  program  verification  [25,26].  Each  of  these 
deductive  mechanisms  is  explained  in  detail  in  the  references  cited; 
consequently,  speolflos  will  not  be  given  here. 

After  developing,  implementing,  and  extensively  testing  these  three 
approaches  to  deduction,  we  have  decided  to  use  the  Boyer-Hoore  theorem 
prover  as  the  general  deductive  neohanlsm  and  to  Implement  speclal- 
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purpose  prows  for  the  specialised  theories  for  tfiioh  fast  decision 
procedures  have  been  devised.  The  sea  an  tic  tableaux  system  was 
eliminated  froa  consideration  because  it  generally  appeared  to  be  very 
tedious  to  use  and  because  Its  achievements  pale  In  comparison  to  those 
of  the  Boyer -Moore  prover.  A  principal  reason  for  the  latter  comparison 
is  that  the  tableau  system  user  was  required  to  supply  instantiations 
manually  when  applying  previously  proved  lemmas.  The  Boyer-Moore 
prover,  on  the  other  hand,  contains  an  efficient  pattern-matching 
mechanism  to  perform  the  corresponding  task  automatically.  We  plan  to 
Invoke  the  fast,  special-purpose  decision  mechanisms  froa  within  the 
Boyer-Hoore  system,  either  automatically  or  under  user  control,  where 
appropriate.  Ultimately,  such  efficient  mechanisms  may  be  Incorporated 
directly  into  the  Boyer-Hoore  package. 

i.  lug  fcmr-ttaarg  Thgar.ai  Pravar 

Tne  Boyer-Moore  prover  has  been  usod  to  prove  an  impressive 
list  of  difficult  recursive  programs  (written  in  the  boyer-Hoore 
theory),  Inducing  a  simple  optimising  expression  compiler  [2],  an 
expression  parser,  a  fast  string-searching  algorithm  [31.  •  mechanical 
theorem  prover  for  propositional  caloulus,  and  an  arithmetic  simplifier. 
It  has  also  proved  a  variety  of  mathematical  theorems,  the  deepest  being 
the  unique  prime  faotorixatlon  theorem  (wnioh  is  derived  solely  froa  the 
Peano  axioms  for  Integers  and  lists  and  previously  proved  theorems). 

We  are  planning  several  extensions  to  the  Boyer-Hoore  prover 

that  will : 

*  Hake  it  easier  to  state  and  prove  many  kinds  of  assertions 
(e.g.,  by  providing  recursive,  schematic  concepts) 

*  Ease  the  burden  on  the  user  during  proofs  (e.g.,  by 
aechanloally  inventing  lemmas) 

*  Inorease  the  prover ' s  competence  In  many  important  domains 
(e.g.,  graphs,  the  arithmetic  of  the  rational  numbers,  and 
combinatorics) . 

Specific  investigations  (supported  tnder  other  contracts)  are  being 
carried  out  in  each  of  these  directions,  but  their  description  la 
necessarily  highly  technical  and  is  beyond  the  scope  of  this  report. 


2.  1  SUBilfUr  I2C  Spsolallxad  Theories 


Prior  to  the  period  covered  In  this  report,  such  eaphesls  was 
placed  on  efficient  mechanical  deductive  techniques  for  speolflo  foraula 
doaalns.  This  eaphasls  was  aotlvated  in  large  part  by  a  need  for  fast, 
autoaatlo,  decision  aechanlsas  In  our  first  systaa  for  verifying  JOCIT 
prograas.  Previously,  aoat  deductive  systeas  designed  speolfloally  for 
prograa  verification  applications  were  of  the  heuristlo,  goal-driven 
type.  The  first  SRI  Prograa  Verifier  [8]  and  a  substantial  part  of  the 
RP6/1  systea  [9]  were  subgoal lng  systeas  that  depended  strongly  on  ad 
noc  heuristics.  While  these  systeas  were  quite  general  and  easy  to 
aodlfy,  they  tended  to  be  unreliable,  lncoaplete,  and  often  too  slow  to 
handle  aaiy  of  the  larger,  aore  ooaplex  verification  oondltlona  In  a 
reasonable  period  of  tlae.  Our  early  experience,  dating  baok  to  the 
RPfi/i  projeot  (1975-76)  and  before,  lndloated  that  a  substantial 
fraotlon  of  the  foraulas  actually  encountered  fill  within  olasses  (so- 
called  decidable  doaalns)  for  Whloh  validity  Is  algorlthaloally 
decidable  (l.e.,  without  recourse  to  heuristlo  techniques).  Observe 
that  a  decision  procedure  (when  applicable)  Is  preferable  to  a  procedure 
that  eerely  proves  validity  (a  proof  procedure).  A  decision  procedure 
will  (for  any  foraula  In  its  doaaln  of  ooapstenoe)  establish  whether 
that  foraula  Is  valid  or  not  valid.  Proof  procedures,  on  the  other 
hand,  can  suffloe  to  establish  validity  for  sons  foraulas  (over  a 
doaaln),  but  the  results  are  inconclusive  when  the  proof  procedure 
happens  to  fail  on  a  particular  foraula.  Suoh  procedures  are  therefore 
often  called  saaldeclalon  procedures .  The  problM  Is,  of  oourse,  that 
decision  procedures  are  known  to  be  theoretically  laposslble  for  aany 
iaportant  doaalna  (e.g.,  even  for  nuaber  theory — the  arlthaetlo  of  the 
Integers  under  addition,  subtraction,  and  aultlplloatlon) . 
Nevertheless,  there  are  slapler  foraula  doaalns  for  whloh  decision 
procedures  are  known  to  exist.  Perhaps  ths  aost  iaportant  of  thess 
doaalns  Is  that  of  Prssburgsr  arlthaetlo*.  Certain  extensions  of  this 


Roughly  speaking,  Presburger  arlthaetlo  oonslsts  of  logloslly 
quantified  foraulas  with  Integer  constants  and  variables  where  only 
addition,  subtraction,  and  aultlplloatlon  by  constants  are  allowed. 
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dona In  and  also  some  of  Its  subdomains  are  of  considerable  relevance  to 
program  verification.  Accordingly,  we  Initiated  a  course  of  researoh 
with  the  ala  of  producing  fast,  non-heurlstlc  algorithms  for  these 
classes  that  could  be  lapleeen ted  and  tested  in  the  RPE/2  systeo. 


That  effort  resulted  in  fast  decision  procedures  for  (1) 
quantifier-free*  Presburger  arltheetlo  [26]  augmented  by  uninterpreted 
function  and  predicate  syabols,  (2)  a  class  of  unquantified  equality 
formulas  with  function  syabols  [25],  and  (3)  deciding  the  "feasibility" 
of  sets  of  linear  inequalities  over  the  integers  or  the  rationale**. 


While  this  work  on  fast  decision  procedures  enabled  us  to 
prove  automatically  aany  of  the  verification  conditions  and  fragments  of 
verification  conditions  encountered  in  the  RADC  efforts,  it  by  no  means 
facilitated  automatic  proof  of  all  of  the  formulas  we  came  across. 


Part  of  the  inadequacy  was  simply  a  matter  of  speed.  Certain 
of  the  formulas  that  we  encountered  had  Boolean  structure  that  produced 
a  combinatorial  explosion  too  large  to  handle  with  a  reasonable 
limitation  on  CPU  time.  A  more  serious  problem  was  slaply  lack  of 
generality.  First  of  all,  the  Immediate  application  of  our  procedures 
was  llmltad  to  quantifier- free  foreulas--l .e.,  formulas,  which,  Mien 
plaoed  In  a  certain  canonical  fora  (prenex  normal  form)r  contain  no 
occurrences  of  existential  quantifiers.  Many  of  the  verification 
conditions  that  arose  contained  such  quantifiers,  but  iwre  otherwise 
similar  to  formulas  In  the  classes  we  treated.  Secondly,  tne  system 
lacked  the  generality  needed  to  deal  wltn  the  semantics  of  a  number  of 
oommonly  occurring  mathematical  operators,  such  as  multiplication, 
division,  and  sst  manipulation. 


X.e.,  excluding  the  use  of  the  logical  quantifiers  "fbrall"  and  "there 
exists". 


A  set  of  arithmetic  inequalities  is  said  to  feasible  (or  satlsflable) 
over  a  domain  0  if  for  each  of  the  free  variables  appearing  in  the 
inequalities  values  in  D  can  be  fotxid  for  Milch  all  the  inequalities  are 
true . 


The  Inability  to  handl*  such  constructs  was  a  direct  result  of 
the  decision  to  stay  within  the  bounds  of  the  decidable.  The  theories 
for  whloh  we  lapleasnted  decision  procedures  are,  In  a  sense, 
dangerously  close  to  tnat  boundary.  For  example,  extending  the  theory 
of  unquantified  Presburger  foraulas  with  funotlon  symbols  (which  Is 
deoldsble)  to  inolude  existential  quantifloatlon  results  In 
undeoldabll ity .  Likewise,  augmenting  (arbitrarily  quantified) 
Presburger  arithmetic  with  even  a  single  untnterpreted  predicate  symbol 
also  takes  one  outside  the  bounds  of  decidability.  The  theory  of 
integer  auitl plication,  and  the  unquantlfled  theory  of  prlaltlve 
recursive  functions  are,  of  course,  also  undeoldable.  Nevertheless,  we 
are  optlalstio  about  the  possibility  of  devising  fast  decision 
procedures  for  other  useful  domains  (e.g.,  the  theory  of  "bags"  or 
ault  1  sets— sets  with  repeated  eleaonts)  that  will  have  a  significant 
lapact  In  proving  verification  conditions. 

We  are  planning  to  continue  these  Investigations  Into 
discovering  fast  decision  procedures  for  such  relevant  deoldable 
theories,  while  at  the  saae  tlae  Implementing  a  unified  slapllfler  for 
•PPlylng  them. 

3.  EkUCfi.  Plena 

We  are  currently  exploring  the  feasibility  of  integrating  the 
Boyer-Moore  prover  with  the  more  specialised  slapllfler.  If  this 
Integration  proves  to  be  inappropriate,  the  current  plan  Is  to  use  the 
slapllfler  as  a  preprocessor  for  the  Boyer<4toore  prover.  That  is, 
verification  conditions  will  be  simplified  (thereby  removing  aueh  of  the 
olutter  typically  contained  In  verification  conditions)  before  a  proof 
Is  attempted  by  the  more  general  Boyer-Moore  prover.  A  second 
possibility  would  be  to  use  simplification  during  the  prooesa  of 
verification  oondltlon  generation,  as  In  some  earlier  verifiers  [6,20]. 

Another  Interesting  Idea  now  being  explored  oonoerns  the 
slapllfler's  ability  to  detect  Invalid  foraulas.  An  Invalid 
verification  oondltlon  can  arise  because  either  the  program  being 
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proved i  Its  spsol float  loos,  or  both  are  "wrong"  and  therefore  in  need  of 
change.  The  question  is,  How  oan  counterexamples  generated  bp  the 
simplifier  be  effectively  used  by  the  designer/verifier's  assistant 
(described  in  the  next  seotlon)  to  show  the  user  what  must  be  changed 
and  what  say  be  affeeted  by  any  suoh  change?  Such  information  would  be 
of  inestlaable  value  in  debugging  a  prograa  and  its  specifications. 


In  summary,  we  have  settled  on  an  approach  to  theorem  proving, 
have  made  significant  advanoes  in  two  complementary  directions,  hsve 
plans  for  further  advanoes,  and  are  in  the  process  of  deciding  the  exaot 
structural  organisation  of  the  proof  system. 


Developing  and  maintaining  formally  verified  programs,  especially 
large  ones,  is  an  Incremental  aotlvlty.  Specifications,  programs,  and 
proofs  are  gradually  built  up  and  frequently  revised.  Consequently,  one 
is  faoed  not  only  with  the  problem  of  constructing  these  data,  but  also 
with  the  oomplex  problem  of  determining  the  effects  of  Incremental 
changes  to  it.  The  previously  described  components  of  the  verifier 
assist  the  user  in  constructing  the  data,  while  the  deslgner/ver lfier's 
assistant  assimes  the  responsibility  for  reasoning  about  inoremental 
changes.  Its  primary  funotlons  are  to  answer  "what"  and  "toy"  questions 
about  the  effects  of  hypothesised  changes  and  to  Integrate  actual 
changes  Into  an  existing  development  In  a  manner  that  keepe  Intact 
previous  work  that  remains  valid.  This  capability  usually  saves  large 
amounts  of  costly  and  unnecessary  reprocessing. 


1 .  Beamon ins  About  Incremental  £QgQgfiA. 


The  assistant  embodies  s  unified  theory  of  how  to  reason  about 
inoremental  ohanges  to  a  design  or  verification.  For  each  development, 
the  assistant  builds  a  detailed  model  containing  Information  about  key 
parts  of  the  program's  design  and  verification  and  their  relationships. 
It  then  applies  its  know lade a — the  same  kind  of  knowledge  an  expert 
would  have — to  integrate  new  or  changed  information  Into  the  existing 


aodel,  always  keeping  lntaot  still -valid  previous  work.  For  exaaple,  If 
tbs  spsolflostloo  of  s  function  Is  changed,  the  assistant  deduoes  uhat 
parts  of  tbs  ver if lost Ion  are  unaffected . 

2.  Bxolalnlnx  the  Effeota  of  Hypothesised  Qianaea 

One  of  the  aost  difficult  probleas  In  designing  and  verifying 
progress  is  trying  to  understand  the  effects  of  a  change.  Before 
changing  the  type  of  an  argusent  In  the  psraseter  list  of  a  function, 
for  exaaple,  It  helps  to  know  what  progress  or  specifications  oould  have 
type  conflicts,  what  part  of  the  verification  could  be  Invalidated,  why 
It  oould  be  Invalidated,  and  so  forth.  The  purpose  of  the  assistant's 
explanation  facility  is  to  aake  this  kind  of  lnforsatlon  available  In 
order  to  give  the  user  a  general  wider standing  of  the  potential  effects 
of  revisions  before  they  are  actually  sade. 

All  "mat"  and  "why"  questions  answered  by  the  explanation 
faolllty  are  variants  of  a  few  baslo  kinds  of  questions.  Several 
sea  plea  are  given  below: 

•  Uhat  are  the  effects  of  ooapleting  the  definition  of 
funotion  X? 

•  mat  are  the  effects  of  changing  its  exit  assertion? 

*  Uhat  are  the  effeots  of  o hanging  the  peraaeter  list? 

*  Uhat  are  the  effeots  of  o hanging  X's  body? 

■  Uhat  Is  affected  if  leaaa  X  Is  sod  If led? 

*  Uhat  f  is  affected  by  altering  type  definition  X? 

•  Uhy  la  T  affected? 

Answers  to  these  questions  vary  In  fora  and  content  according  to 
context.  The  questions  are  understood  using  a  staple  pat tern -Batching 
soheae,  that  works  well  for  the  Halted  doaaln  of  dlsoourse.  The 
assistant  then  uses  Its  theory  of  lncreaantsl  changes  to  deduoe  what 
could  be  affected  If  the  lndloated  ohange  were  aade.  It  is 
straightforward  to  then  foraat  the  answer  for  fcigllsh  output. 
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3.  Currant.  Status  and  future  Plana 

A  working  prototype  of  a  designer/verifier's  assistant  was 
developed  in  the  reoent  Fh.D.  thesis  of  Morloonl  [20].  Effort  over  the 
past  year  has  been  spent  on  investigating  the  principles  which  underlie 
this  original  prototype.  We  have  successfully  Identified  and  explained 
the  fundaaaital  ideas  behind  this  work  and  described  our  results  [19]. 
With  this  Increased  understanding,  we  can  now  proceed  to  develop  such  a 
facility  for  the  JOVIAL  verifier. 

There  are  two  coapleaentary  directions  our  future  work  In  this 
area  will  follow.  First,  it  is  tlae  to  develop  a  foraal  aathaaatioal 
basis  for  the  (currently  lnforaal)  theory  of  how  to  reason  about 
lncreaental  changes.  We  feel  that  this  is  possible  because  of  the 
experience  gained  froa  our  previous  investigations  and  the  prototype 
lapleaentatlon,  both  of  which  support  the  validity  of  the  key  ideas. 
This  foraal lxat ion  is  necessary  if  wa  are  to  attain  the  ultlaate  goal  of 
providing  a  foraal  basis  for  the  entire  JOVIAL  verifier.  Second,  we 
will  apply  the  ideas  described  in  [19]  to  acccaaodate  JOVIAL  and  the  SRI 
Hierarohloal  Davelopaent  Methodology.  This  will  result  in  a  working 
coaputer  program  capable  of  determining  the  effects  of  lncreaental 
changes  and  of  answering  questions  about  the  effects  of  hypothesised 
changes  to  any  JOVIAL  prograa  developed  using  our  verifier. 


IV  MILESTONE  EXAMPLES 


He  are  considering  several  progress  for  uae  In  deaonstratlng  the 
utility  of  the  JOVIAL  verifier.  The  prograas  verified  In  previous 
systeas  were  characteristically  saall  In  slxe,  textbook  or  toy  exaaples. 
They  lnolude  oertaln  array  sorting  and  rearrangeaent  prograas;  algebraio 
coaputat ton  progress,  such  as  square  root,  quotient,  factorial,  and 
exponentiation;  and  tree-searching,  pattern-aatohlng,  and  utlflcatlon 
prograas.  Our  goal  Is  to  foraally  specify  and  verify  a  real  software 
coaponent  that  Is  Intended  for  actual  use. 


He  have  tentatively  decided  to  verify  oertaln  (as  yet  undeteralned) 
coaponent s  froa  two  aajor  systeas  currently  being  developed  In  the 
Coaputer  Science  Laboratory  at  SRI  International.  The  first  systea, 
called  SIFT  (Software  Iaplsaented  Fault -Tolerance)  [29),  Is  an 
ultrareliable  coaputer  for  orltloal  aircraft  control  applications  that 
aohleves  fault  toleranoe  by  the  replication  of  tasks  aaong  processing 
units.  The  seoond  systea,  oalled  PSOS  (Provebly  Secure  Operating 
Systea)  (21),  is  a  secure  capability-based  operating  systea.  Both  SIFT 
and  PSOS  are  being  developed  vnder  other  projeots  In  the  Coaputer 
So fence  Laboratory  and  are  in  various  stages  of  design  and 
lapleaentatlon.  The  disousslon  below  gives  a  brief  overview  of  each  of 
these  systeas.  For  aore  detailed  descriptions  the  reader  should  refer 
to  [29). 


Modem  ooaaerelal  Jet  transports  use  coaputers  to  oarry  out  aany 
functions,  such  as  navigation,  stability  augaentatlon,  flight  control, 
and  systea  aonltorlng.  Although  these  ooaputers  provide  greet  benefits 
in  the  operation  of  the  alrorsft,  they  are  not  orltloal.  If  a  coaputer 
falls,  it  Is  always  possible  for  the  aircrew  to  ass  uae  its  fmetlon,  or 


for  the  function  to  be  abandoned.  (This  say  require  significant 
changes,  suoh  as  diversion  to  an  alternative  destination.)  NASA,  In  Its 
Alroraft  foergy  Efficiency  Prograa,  Is  currently  studying  the  design  of 
new  types  of  aircraft  to  reduoe  fuel  oonsuaptlon.  Such  alroraft  will 
operate  with  greatly  reduoed  stability  aarglns,  which  aeans  that  the 
safety  of  the  flight  will  depend  upon  aotlve  controls  derived  froa 
ooaputer  outputs.  Ccaputers  for  this  application  aust  have  a 
reliability  that  Is  coaparable  with  other  parts  of  the  aircraft.  The 
frequently  quoted  reliability  requlreaant  Is  that  the  probability  of 
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fall  ire  should  be  less  than  10  per  hour  In  a  flight  of  ten  hours 
duration.  This  reliability  requireaent  Is  slallar  to  that  deaanded  for 
aanned  space-flight  systeas. 

As  the  naae  "Software  lapleaented  Fault  Tolerance"  lapllea,  the 
oentral  concept  of  SIFT  la  that  fault  toleranoe  Is  acooapllshed  as  auch 
as  possible  by  prograas  rather  than  hardware.  This  lnoludes  error 
detection  and  correction,  diagnosis,  reconfiguration,  and  the  prevention 
of  a  faulty  unit  froa  having  an  adverse  effect  on  the  systea  as  a  whole. 

The  structure  of  the  SIFT  nardware  Is  shown  In  Figure  IV-1. 
Coaputlng  Is  oarrled  out  by  the  aaln  processors.  Bach  processor's 
results  are  stored  In  a  aaln  aeaory  that  Is  uniquely  associated  with  the 
processor.  A  processor  and  Its  aeaory  are  connected  by  a  conventional 
hlgh-bandwldth  connection.  The  1/0  processors  and  aeaorles  are 
structurally  slallar  to  the  aaln  processors  and  aeaorles,  but  are  of 
auch  saaller  coaputat tonal  and  aeaory  oapaolty.  They  oonneot  to  the 
Input  and  output  units  of  the  systea,  which,  for  this  application,  are 
the  sensors  and  aotustors  of  the  aircraft. 

The  SIFT  systea  executes  a  set  of  £gaJfc&,  each  of  which  consists  of 
a  sequence  of  Iterations.  The  Input  data  to  each  Iteration  of  a  task 
oonslst  of  the  output  data  produced  by  the  previoue  Iteration  of  soae 
collection  of  tasks  (tfiloh  aay  Include  the  (ask  itself).  The  input  and 
output  of  the  entire  systea  Is  acooapllshed  by  tasks  exeouted  In  the  1/0 
processors.  Reliability  Is  aohleved  by  having  eaoh  Iteration  of  a  task 
executed  independently  by  a  niaber  of  processors.  After  executing  the 
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Iteration,  a  processor  plaoes  the  Iteration's  output  In  the  aeoory 
associated  with  the  processor.  A  processor  that  uses  the  output  of  this 
Iteration  deteralnes  Its  value  by  exaalnlng  the  output  generated  by  eaoh 
processor  that  exeouted  the  Iteration.  Typically,  the  value  Is  ohosen 
by  a  "two  out  of  three"  vote.  If  all  copies  of  the  output  are  not 
Identical,  then  an  error  has  occurred.  Such  errors  are  reoorded  In  the 
processor's  eeaory,  and  these  records  are  used  by  the  executive  systea 
to  deteralne  which  units  are  faulty.  When  the  global  executive  has 
decided  that  a  processor  has  becoae  faulty,  it  reconfigures  the  systea 
by  appropriately  changing  the  allocation  of  tasks  to  processors. 

SIFT  has  been  designed  with  the  Intent  of  proving  that  It  aeets  its 
stringent  reliability  requlraaents.  Poraal  aodels  with  which  to  analyze 
the  probability  of  systea  failure  have  been  constructed,  and  we  intend 
to  prove  that  these  aodels  accurately  describe  the  behavior  of  certain 
coaponents  of  the  SIFT  systea. 

B.  Secure  Operating  Svataa 

PSOS  (Provably  Secure  Operating  Systea)  Is  a  general-purpose, 
capability-based  operating  systea  designed  to  aeet  certain  security 
requlraaents.  The  two  aaln  properties  desired  of  PSOS  are  that  there 
shall  be  no  unauthorized  reading  or  writing  of  lnforaatlon.  PSOS  Is 
hierarchically  structured  Into  the  self-contained  levela  of  abstraction 
shown  below: 

*  User  envlronaents 

*  User  input-output 

*  Procedure  records 

*  User  processes 

*  User  objeots 

*  Directories 

*  Extended  types 

■  Virtual  aeaory  (asgaentatlon) 

■  Paging 

*  Systea  processes  and  Input-output 

*  Basic  operations  (e.g.,  arithaetlo) 


*  Real  aeaory 

*  Capabilities  and  Interrupts. 

Each  of  these  levels  provides  sn  abstraction  uaeful  In  the 
lapleaentatlon  of  the  operating  system.  The  plan  Is  to  verify  at  least 
one  of  the  orltioal  levels  of  this  hierarchy. 
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FIGURE  V-1  RESEARCH  ANO  DEVELOPMENT  PLAN 


exercised  on  exaaples  for  three  months,  st  which  ties  we  naturally 
expect  certain  now  unforeseen  problems  to  surface. 

Inadequacies  found  in  the  first  version  of  the  verifier  will  be 
reaoved  (if  theoretically  and  practically  possible)  in  the  second 
version  of  the  verifier,  which  will  be  developed  during  the  six-month 
period  from  \  July  1980  through  31  December  1980.  This  second  version 
of  tne  verifier  will  then  be  used  in  completing  the  design  and 
verification  of  our  two  milestone  examples. 

d.  mi  gat  ana  Exaaalca 

Perhaps  the  main  overall  characteristic  of  our  plan  is  the  example- 
driven  nature  of  tne  verifier's  development.  We  have  taken  it  to  be 
axiomatic  that  early  attention  to  real  examples  is  critical  if  we  are  to 
produce  an  effective  JOVIAL  verifier.  To  a  large  extent,  we  expect 
problems  encountered  while  attempting  to  verify  certain  real  programs  to 
drive  the  entire  technical  direction  of  the  verifier. 

Consequently,  as  explained  in  Section  IV,  we  carefully  chose  to 
consider  (as  yet  undetermined)  critical  parts  of  a  secure  operating 
system  and  a  fault-tolerant  avionics  computer.  Work  on  these  examples 
will  begin  in  January  1980.  Attention  will  Initially  focus  on  analyzing 
the  appropriateness  c?  their  design  and  specification,  and  on  making  any 
adjustments  needed  for  verification  purposes.  The  verification  of  both 
exaaples  will  begin  as  soon  as  possible,  with  the  JOVIAL  verifier  being 
used  to  an  increasingly  greater  degree  as  its  development  progresses. 
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This  report  n«s  described  the  progress  asde  during  the  period  fro* 
1  November  1977  through  3’  December  1978,  regarding: 


Tne  analysis,  enhancement,  and  formal  definition  or  the 
JOVIAL  programming  language  (J73/I) 

Tne  organisation,  c<.  Meal  development,  and  Implementation 
of  tne  JOVIAL  verlflei 

Tne  seleotlon,  analysis,  and  verification  of  two  real 
systems  of  significant  else  and  complexity,  critical  parts 
of  whloh  will  be  written  In  JOVIAL  and  verified  by  the 
JOVIAL  verifier. 


A  comprehensive  plan  for  completing  each  remaining  task  has  also  been 
desorlbed .  This  plan  oalls  for  a  considerable  amount  of  work  In  each  of 
tnese  three  areas  during  the  oomlng  year,  Including  the  completion  of 
the  Initial  version  of  all  components  of  the  JOVIAL  verifier  by  31 
December  1979- 
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Appendix  A 


A  FORMAL  GRAMMAR  FOR  JOVIAL-J73/I 


B  BC  BEGIN  BIT_BYTE  BLOCK  BY  CHAR  CQHPOOL  COPY  DEF 
DEFAULT  DEFINE  DIGIT  DOUBLE  E  EJECT  ELSE  END  F  FLOAT 
FOR  GOTO  IF  ITEM  LETTER  LINKAGE  LIST  LOC  LOGOP  M  MARK 
IMD  NOLIST  NOT  NUMBER  NUMOP  OTHERCHARACTER  OVERLAY  P 
PROC  PROGRAM  REDUCIBLE  RELOP  RETURN  ROLLBACK  SHIFT 
SIGN  SIZEKEY  SKIP  STATUS  STOP  STRING  SU  SWITCH  SYMBX 
TABLE  THEN  TR  TRACE  V  WHILE 


:  eoapll 

1  compilation  eoapll 


dlrplusq 


/•  A*/  dlrplusq 


/•  9*/  dlr_body 


/•  22*/  blt_foraulaq 


/•  2**/  lattarq 


/•  26 •/  llat_oontrol 


/•  28*/  ayabola 


/•  30*/  ayabol 


/•  36*/  mat 


:  C  OH  POOL  ooapool_body 
I  SKIP  lattarq 
I  BEGIN 
I  END 

!  TRACE  blt_fbraulaq  naaallat 
i  COPY  ehar_oonat 
!  LIST  llat.oontrol 
!  EJECT 

I  NOLIST  Uat_oontrol 
!  LINKAGE  ayabola 
!  DOUBLE  naaallat  •;« 

!  ROLLBACK 
I  REDUCIBLE  ; 


I  blt_foraula  ; 


!  LETTER  ; 


!  'DEFINE/COPY'  ; 

:  ayabol 

'■  ayabcla  ayabcl  ; 

:  SYMBOL 
S  SIGN 
!  nuabar 
!  oonat 
I  ooaaant 
I  dafi  na_oal  1  ; 

:  SYMBOL  ; 


AA 


/•  37*/  define_call 
/•  38*/  a_defpqaq 

/•  40*/  a_defpqs 

/•  42B/  a_defpq 

/•  44*/  coapool_body 

/•  46*/  coaaent 
/•  *•?•/  Integer 

/•  51*/  constq 

/•  53*/  oon»t 

/•  57*/  nuaerlc_oonat 

/•  60s/  bit_oonat 
/•  6 1 •/  bead  a 


:  naae  a_defpqaq  ; 

a 

e 

I  e_defpqa  ; 

:  a_defpq 

I  a_defpqa  ' , '  *_defpq  ; 

a 

e 

I  STRING  ; 

:  oonatq  naaea2 
I  '('  oonatq  •)'  ; 

:  STRING  ; 

:  number 
!  blt_eenat 
!  qual_atatus_oonat 
I  ' "  character  ; 

:  con at 

!  ; 

:  nuaer lc_oonat 
!  blt_oonat 
!  char_oonat 
I  CHAR  •(•  const  •)•  ; 

:  integ er_oonat 
!  float_eonat 
!  FLOAT  • ( •  const  • ) •  ; 

:  '0NE:FIVE'  B  •••  beads 
:  bead 

!  beads  bead  : 


/•  63*/  ehar_oonat 
/•  6**/  chars 


/•  66*/  character 


/•  70*/  bead 


s  •••  ohara  "•  ; 

:  character 
I  chars  oharaoter  ; 

:  LETTER 
!  DIGIT 

!  NARK 

t  OTHERCHARACTER  ; 

:  DIGIT 

I  'LETTER/A: V'  ; 


/•  72*/  Integer _ccnst 

t 

/•  75s/  qual_status_const 
/•  76*/  number 

/•  78*/  number.formula 


number 
status_const 
qual_status_ccnst  ; 

V  •(’  name  SYMBOL  •)*  5 

NUMBER 

!  • ( •  number.formula  ' ) '  ; 

:  Integer 

!  • PLUS/MINUS/NOT •  number_formuia 
!  number_formula  •OP.NOT**' 
number_formul  a 
!  SHIFT  •(’  number_formula 
number_formula  ')' 

I  'ABS/SGN '  number_formul a 
!  ' BITOF/IMT*  •{'  numfbr*_const  •) 
!  •('  number_formula  ' ) ' 

!  • MACHINE. PARAMETER’ 

!  ei*e_funcall  ; 


A6 


/•  87V  nuafbr«_oonat 


s  nuaner_foraula 
I  oonat  ; 


/•  89V  alxa_funoall 


•  SBEII!  '(•  al aa_arg  •  )•  • 


/•  90*/  al sa_arg 


:  for  aula 

I  naaa  ; 


/•  92*/  fioat_oonat 

/•  94  V  float.oonat 1 

/•  95V  algnq 


:  rioac.oonac 1 
I  float_oonat2  ; 

:  MMBER  E  algnq  NUMBER 

praol along  ; 

:  'PLUS /MINUS' 

I  i 


/•  97V  praelaionq 


I  H  pluaq  NUMBER  ; 


/•  99V  pluaq 


/•101V  rioat_oonat  2 


5  float_prf*  axponq  praelaionq  ; 


/•102V  float jr fa 


/•104  V  nuaOarq 


/•106V  axponq 


:  NUMBER 

I  nuaberq  ».»  NUMBER  ; 

a 

a 

I  NUMBER  ; 


I  I  algnq  NUMBER  ; 
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/•108#/  atatua_co88ta 

/•UO*/  atatua_oo8at 
/•111*/  8tatU8li8t_d80l 

/•l 12*/  atatua_bcdylq 

/•11M/  atatua_bodyl 

/•116*/  atatua_body 

/•1 17*/  888832 

/•119'/  naa«2 

/•121*/  coapool_pro«raa_j>rocd3c 

/•  12***/  eoapool 

/•125*/  capl_aouroa_body 


:  atatua_conat 
I  atatua_oonata 

atatua_oonat  ; 

:  V  •(•  SYMBOL  •)'  ; 

;  STATUS  naaa  o_a_lnte«arq 
atatua.oonata  atatua_bodylq 


1  atatua_bodyl  ; 

:  atatua_bcdy 

I  atatua.bodyl  atatua_body  ; 

:  ' [ '  o_a_int8*8r  ' ] ' 
atatua.ocnats  ; 

:  n*a a2 

|  888882  88882  ; 

:  8888 

!  '(»  8888  *)'  ; 

:  008  poo  1 
I  prograa 
!  proc_dec 1  ; 

:  COM POOL  8888 

o8pl_aourc8_body  ; 

:  cos poo l_d8c 1  * 

!  BEGIN  co8pooI_d8c la  END  ; 
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/•I 27*/  ooapool_<leola 


:  o  <hi  poo  1 _ dec  1 

i  ooapoc]_dec  1 »  coapool_dec  1 


/•130V  coapool_dec  1 


:  overlay_decl 
t  data_decl 
I  naae_decl 
!  proc_decl 
I  deflne_decl 
!  atatual iat_decl 
I  def_decl  ; 


:  ite«_decl 
i  table_decl 
!  blockaded 


/•1*0V  ltea_decl 


ITB<  naae  al loc_specq  ldasc 
ldecl_tallq  ; 


/•U1»/  alloc. 


IN/RESERVE 


/•1M*/  ldecl_tall 


!  e_a_oonat 


/•H7V  loc. 


/•150*/  blook_decl 


BLOCK  naae  allcc_apecq 
block_body  ; 


/•151*/  blook_body 


/•15**/  block_bedy2sq 


•  t  •  I 

•  t 

I  data_decl 

!  BEGIN  blook_body2sq  END  ; 


I  block_body2s  ; 


/• 1 56*/  block_body2s  :  block_body2 

!  block_bcdy2s  block_body2 


/•158§/  block_body2 


/•163*/  table_decl 


•  •  •  « 

•  » 

!  data_decl 
!  overlay_decl 
'  statusl Ist.decl 
!  deflne_decl  ; 

:  ord_table_deel 
■  sp«c_tabl  e.dacl  ; 


/•165*/  ord_table_deol 


/•166#/  dlmensicn_llst 

/• 167*/  dimensions 


/•I 69*/  lowered! mq 


/• 171 •/  structure 


:  TABLE  name  allcc_specq 
dlmenslon_list  structure 
packingq  ord_table_tall 

:  •(•  dimensions  ']'  ; 

:  lower.dimq  o_s_lnteger 
!  dimensions  • lower _dlmq 
o_s_lnteger  ; 


!  c_a_lnteger  •  s  *  ; 
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/•173V  paclcingq 


:  ldesc  oonstantl lstq 
!  oonstantl lstq 

ord_table_body 


/•I 75*/  or<H_Ut>l«_tail 


/•177*/  ord_tabla_bcdy 


!  ord_tabl«_id«cl 
i  BEGIN  ord_table_body_decl sq 


/•I 80*/  crd_table_body_decl  sq 


/•I 82 •/  ord_.table_body_.decl s 


ord_table_ldecl 
statusl lst_decl 


/•18<#/  ord_table_body_decl 


deflne_decl 


ITEM  name  ldesc  packlngq 
constant] Istq  ; 


/•  1 87*/  crd_table_ldecl 


/■i88*/  constant  1 istq 


;  ccnstantliat 


ccnst_indxlq  ocnst_list_el 
ccnst_list_tallsq  ; 


/•190*/  constantlist 


/•191#/  const. Indxlq 


•  oonst_lndxl  ' 


/•l 93*/  ccnat_in<lxl 


/•195V  const_llst_el 


/•197#/  const_ll3t_el l 


/•2Q1*/  const_ll3t_elq 


/•2 03*/  const _11 st_ti 1 1 aq 


/•205§/  ccnst_l 1 st_tal l s 


/•2 07*/  spec_table_<l«cl 


:  c_s_integer 

!  const_lndxl  c_s_lnteger 

:  ecnat_llst_«M 
i  const_ll8t_el 

ccn3t_llst_el  1  ; 

:  o_3_con3t 
i  LOC  •(•  lcc_arg  •)• 

!  nuaber  '(•  ocnst_llst_el  q  •) 

I  • 

«  I 

!  ecn3t_]lst_el  ; 

!  ccnst_ll 3t_t«l 1 3  ; 

:  ccnst_ln(Jxl  conat_list_el 
!  ecn3t_llat_tal la  oonst_indxl 
conat_llat_el  ; 

:  TABLE  naae  alloo_specq 
<JiBenalcn_llst  structure 
NUMBER  spec_tabl e_decl_tai 1 


/•208*/  spec_table_decl_tal  1  :  tdeac  packtngq  '[•  nuaber 

cnuaberq  •]'  ccnstentl  Ist.q 
!  ccnstentl Istq  ' ; ' 
spec_table_bcby  ; 

/•210*/  apec_table_body  :  •;* 

!  spec_table_ldecl 
!  BEGIN  spec_tabl  e_body_decl  sq 


/•213*/  apec_teble_ldeol 


ITEM  nut  ideac  peoklngq 
• C •  onu«berq  •]• 
constant! 1st q  ; 


/•214*/  spec_table_body_<lecl  aq 


apec_tabl e_body_decl 
ap«c_tabl  a_body_cJ«cl  a 
sp«c_tabl e_Ocdy_dacl 


/•2 16*/  spec_t»ble_body_<lecla 


ap«c_tabl e_ld«cl 
statusl lst_decl 
deflne_<Jecl  ; 


OVERLAY  over lay_lteeq 
everlay_e*pr  ; 


/•221*/  cverlay_<lecl 


/•222§/  overlay_lte«q 


nuaoer.bitccnat 


/•22A*/  nu»ber_bltcenat 


bltccnat 


/•226#/  overlay_«pr 


over lay_st ring 
cverlay_e«pr  1 : 1 
everlay_atrlng 


:  cverlay_elee«nt 
1  cverlay_string 

overlay.eleaent 


/•22fl*/  overlay_atring 


/•2 30*/  ovarlay_alaa«tt 

/•233*/  •*tern»l_<lecl 
/•23*«/  «* tern*l_d«cl_t>o<ly 

/•2 36*/  Mt_bcdy_decl 


/•2«2«/  «xt_bcdy_d*claq 

/•2M*/  «L_bcdy_<J«cls 

/•2*6#/  dafln«_<l«cl 

/•2* 7*/  d«fln«_atrlng 
/•2«8»/  f_<J«fplq 

/•250*/  f_d«fpl 

/•252#/  d«f_<J«cl 


:  nuabar 

I  MB* 

I  •('  evarlay_«pr  •)•  ; 

:  ‘DEF/REF'  ext«rn»l_d»c l_body 

:  •*  t_body_d«cl 
:  BEGIN  •*t_body_a«cl sq  END  ; 

•  •  •  • 

•  t 

I  <Ut*_decl 
'  n*a«_d«cl 
!  proo_d«c  1 
!  <J«fin«_decl 
!  atatual lst_d«cl  ; 


!  e*L_bcdy_decl  a  ; 

:  •xt_bcdy_d«cl 

!  «t_bcdy_decl  a  •xt_bcdy_d*cl 

:  DEFINE  naa*  f_«*fplq 
dafln*_atrin*  ; 

:  STRING  ; 

!  •(’  f_<*afpl  ')•  ; 

:  LETTER 

!  f_dafpl  V  LETTER  ; 

:  DEF  q«f_d«cl_be<ly  ; 
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/•25B*/  daf_dacl_Pody 


:  dat*_dacl 

I  BEGIN  def_dacl2a  END 


/•2 55*/  daf_dacl2a 


def_dacl2 

daf_dacl2a  daf  dacl 2 


/•25 T/  daf_dacl2 


:  d«t»_decl 
I  daflne_decl 
I  atatual lst_dacl 
!  daf  dacl 


/•262*/  prcgraa 


/•263#/  proc_dacl 


proc_clauaa  prccdlrpl  uaq 
atat_dacl  ; 


/•2 6M/  proc.clauaa 


PROC  naaa  data_allocq 
ftoplq  •}•  ; 


/•2 65*/  prccdlrpl  uaq 


prccdlrpl us 


/•267#/  prccdlrpl us 


:  prccolr 

!  prccdlrpl ua  procdlr 


/•269*/  procdlr 


>'  TRACE  Dlt_for»ulaq 

naaallat 

I*  REDUCIBLE 
I*  LINKAGE  ayabcla  ; 


/•2 72*/  data_allocq 


IN /RESERVE/ AT* 


/•27**/  floplq 


:  prcc_flopl 
J  fh_fipl  ; 


/•2 76*/  proc_flopl 
/•277»/  fh_ripl 
/•278*/  ldesccq 

/•280#/  Idesc 

/*283*/  cnumberq 

/•285#/  trq 

/•287*/  Id  esc_tal 1 

/•289*/  o_s_ocnat 

/•291*/  flpsq 

/•293*/  namelist 


:  *(•  flpsq  fbps  •)'  ; 
:  •('  namelist  ')'  ldescoq 


•  Id esc  ldesc_tall  ; 

:  BC  numberq 

!  F  trq  niaberq  cnumberq 
!  SU  numberq  nameq  ; 


NUMBER 


TR 


I  c_s_oonst  ; 

:  const 

:  • PLUS/MINUS ’  const  ; 

:  nemel 1st 

I  a 
•  9 


:  nue 

!  MStllit  naae  ; 


/•295#/  fops 


:  nemel  1st 


■ '  , 


/•296V  atat_dacl 


/•298V  atataaant 


:  atat 
I  alapla_if 

I  naaa  aaaartq  atataaant 


/•301V  <3 eel 


:  aaaert_decl 
!  data_dacl 
!  atatuallat_deel 
!  deflne_decl 
I  naae_decl 
!  proc_decl 
!  axtarnal_dac] 

!  BEGIN  dacla  END 


/•309V  deola 


ASSERT IN/OUT’  foraula 


/•312V  atat 


aaaartq  atat 


/•315V  alapla.atat 


1  aaalgn^atat 

I  gctc_atat 
I  ratum_atat 
I  atop.atat 
I  loop_atat 
I  if_atat2 
I  awltatv_atat 
I  procoall_atat 
I  aaaart  atat  : 


/•325#/ 

alnple_if 

:  IF  bit_fbraula  ' ; '  stataaan 

/•3261/ 

lf_st»t2 

:  IF  blt_foraula  ' stat 

ELSE  ststeaant  ; 

/•327*/ 

coapd_stat 

:  BEGIN  stat_declplusq 

label sq  END  ; 

/•32fl#/ 

stat_declplusq 

• 

i  stat_deolplus  ; 

/•330*/ 

stat_declpl us 

:  stat.decl 

!  stat_decl  pi  us  stat_decl  ; 

/•332#/ 

labelsq 

: 

S  labels  ; 

/•33*#/ 

lapels 

:  nsae  ' : ' 

!  labels  naae  ' : *  ; 

/•336«/ 

assign.stat 

:  vara  'a'  formula  ; 

/•337»/ 

gctc_stat 

:  GOTO  naae  ' ; '  ; 

/•338#/ 

return_atat 

:  RETURN  naaeq  ; 

/•339*/ 

stop.stat 

:  STOP  ; 

/•3*0V 

swltch.stat 

:  SWITCH  nuaerlc.foraula  * ; * 

s*rltch_tallq  ; 

/•3*1#/ 

swi toh_tal 1 q 

:  BEGIN  sw_body  label sq  DID  ; 

/•3*»2*/ 

naaes 

:  nsae 

!  AAMAff  MAMA 


/•3**#/  sw_body 


:  aw_bodyl 

I  »w_body  8H_body 1  ; 


/•3*6*/ 


/•3*»7«/ 


/•3*9*/ 


/•351*/ 


/•353*/ 


/•355»/ 


/•357»/ 


/•359*/ 


/•36l»/ 


/•363*/ 


/•36*«/ 


s*_body l 


:  '£'  aw_llstq  stateaent 
oouaq  ; 


cowtq 


sw_] i stq 


I  sw_l  1  st  ; 


sw_i  1  st 


:  awjistl 

!  sw_llst  • , •  sH.llstl  ; 


sm_1 1 st  1 


:  DEFAULT 

I  o_a_integer  oa_lnt_tallq  ; 


c_s_integerq 


I  '['  c_a_lntager  • 


c_s_lnteg«r  :  integer 

!  ' PLUS /MINUS •  Integer  ; 


o«_int_teiiq 


I  o_a_lnteger  ; 


lcop.stat 


:  whlle.stat 
I  fbr_atat  ; 


1 1  e_at*t 


:  WHILE  essertq  bit_fbraula 
stateaent  ; 


fbr_stat 


:  FOE  naae  ' : '  essertq 

oontrols  atateaant  ; 
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/•365#/  aaaartq 


/•367*/  control* 


/•369#/  control a2q 


/•373*/  t«lla_foraq 


t 

t  UHrt_itit  ; 

:  control aBq 
t  fbraula  oontrols2q  ; 


BY  nua«rlc_foraula  whi 1 e_foraq 
THEN  foraula  whlla.foraq 
WHILE  blt_foraula  by_thanq  ; 


!  WHILE  bit_foraula  ; 


/•375*/  by_thenq 


/•378*/  aaaert_atat 


/•379*/  naaaq 


S  BY  nuaarlc_foraula 
!  THEN  foraula  ; 


:  'ASSENT/ ASSUME/ PROVE' 
foraula  ';'  ; 


!  naaa  ; 


/•38l«/  vara 


/•383»/  var 


/•385*/  naaad.var 


/•387*/  acalar_var 


:  var 

!  vara  var  ; 

:  naaad_var 
{  funotion_var  ; 

:  acalar.var 
S  lnq*i*4_var  ; 

:  naaa  baa«_foraq  ; 
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/* 388»/  baaa_formq 


I  numar 1 o__formu  l  a  ; 


/•390«/  lndaxad_var 


/•391»/  lndloes 


/•393#/  functlon_vmr 


/•39«#/  tallq 


/•396*/  formula 


/•399*/  numario_formula 


/•<06*/  ohar_fomula 


/MlO*/  char_jrar 


:  Mil  '('  lndloaa 
baaa_fbmq  ; 

:  nu«arlc_ formula 
I  lndloaa  numerlc_formula 

J  BITJBYTB  '(’  named_var  *,» 
numerlc_fomula  tallq  •)' 

a 

I  nuaarlojTbrmula  ; 

:  char_formula 
t  blt_fbrmula 
J  numar ic_fo rmul a  ; 

:  numarlo_oonst 

1  var 

2  ftincall 

2  blt_femula 

2  'PLUS/M1NUS '  numar 1 c_fo rmul • 
2  numar l e_fbrmula  NUHOP 
numarlc_fbrmula 
I  '('  numar  rmul  a  •)•  ; 

:  char_oonst 

1  ohar_var 

2  funcall 

I  '('  char_formula  •)'  ; 

:  naaad_rar 
I  funotlon_vmr  ; 
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/<M12»/  bit_fbraula 


/•M20*/  blt_var 


/•M23*/  logloal_foraula 


/•126*/  bitfn_taUq 

/M28*/  ral_foraula 
/M29*/  data_baseq 

/M31*/  proceall_atat 

/M3 2*/  funoall 
/•*»33*/  Oopl9 


:  blt_oonat 
S  bit_var 
!  funoall 
t  loglcal_foraula 
i  r«l_foraula 
t  •(•  blt_fbraula  •)' 

I  nuaario_foraula 
!  char_foraula  ; 

:  naaed_var 
5  lnd«xe<l_var 
1  funotion_var  ; 

:  blt_foraula  LOOOP  bit_foraula 
!  MOT  blt_foraula 
J  SHIFT  •('  blt_for»ula  *,» 

nua«rlc_foraula  bltfn_tallq 
•)'  ; 


!  nua«rle_ft>raula  ; 

:  foraula  RELOP  foraula  ; 

9 

J  '#•  nuaarlc^fbraula  ; 

:  naae  data_bas«q  a_loplq  • ; 

:  naae  datg_baseq  '('  UP*fl  *)' 


I  '(•  Oopl  •>'  J 
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/M35*/  Oopl 


:  OP* 

I  Op*q 


•  •  I 


*_0pl 


/•*37*/  *_opl 


/•*»39*/  OP» 


OP 

Op* 


/•mi*/  Op 


:  naae  d«t*_b**«q 

!  fbraula 

!  nuaerlc_foraul» 


op*q 


!  Op* 


/•M6*/  *_op 


ABS/SGN  ASSERT/ ASSUME/ PROVE 
ASSERTIN/OUT  B  BC  BEGIN  BITOF/INT  BITJYTE  BLOCK  BY  CHAR 
COM POOL  COPY  OEP  DBF/REF  DEFAULT  DEFINE  DBF INS/ COPY  DIGIT 
DOUBLE  E  EJECT  ELSE  END  F  FLOAT  FOR  OOTO  IF  IN /RESERVE 
1N/RBSBRVB/AT  ITEH  LETTER  LETTER/ A: V  LINKAGE  LIST  LOC  LOOOP 
H  MACHINE. PARAMETER  MARK  NMD  NOLIST  NOT  NUMBER  NUMOP  ONE: FIVE 
OP. NOT**  OTHBRCHARACTER  OVERLAY  P  PLUS/MINUS  PLUS/MINUS/NOT 
PROC  PROGRAM  REDUCIBLE  RBLOP  RETURN  ROLLBACK  SHIFT  SIGN 
SIZBKEY  SKIP  STATUS  STOP  STRING  SU  SWITCH  SYMBOL  TABLE  THEN 
TR  TRACE  V  WHILE  [  ] 


«.  Dsflnlt  Ions  Ql  Ulfi.  fatanralflila  (HPSQfUSI) 


The  first  element  of  each  parenthesized  Item  Is  the 
aet at era Inal ,  and  the  following  elements  are  Its  alternative 
Instances.  Thus  SU  stands  >'or  an  S  or  a  U. 


(SU  S  U) 

(A3SERTIN/0JT  ASSERTIN  ASSERTOUT) 

(BC  B  C) 

(TR  T  R) 

(DBF/ REF  DEP  REF) 

(BIT/BYTE  BIT  BYTE) 

(IN/RESERVE/ AT  IN  RESERVE  #) 

(RELOP  «<><»>*<>) 

( LOGOP  AND  OR  XOR  EQV) 

(NUMOP  ♦  -  •  /  \ 

(OP. NOT”  ♦  -  •/  \  «<><*>*<>  AND  OR  XOR  EQV) 
(PLUS/MINUS  ♦  -) 

(ONE: FIVE  1  2  3  A  5) 

( ASSERT/ ASSUME/PROVE  ASSERT  ASSUME  PROVE) 

(DEFINE/COPY  DEFINE  COPY) 

(SIGN  ♦  -  •/  \  ••*<><*>«<>  ,  :  ;  I  (  )  (  ]  # 

NOT  AND  OR  XOR  EQV  BEGIN  END) 

(PLUS/MINUS/NOT  ♦  -  NOT) 

( ABS/SGN  ABS  SGN  ) 

(BITOF/INT  BIT  OF  INT) 

(IN/RESERVE  IN  RESERVE) 

(SIZEKEY  B1TSIZE  BYTESIZE  UQRDSIZE) 

(MACHINE.  PARAMETER  BITSINBYTE  BITS  INN OR  D  LOCSINUORD 
BYTESINWORD  AODRESSSIZE ) 

(NMD  NMD) 

(LETTER  ABCDEFGHIJKLMNOPQRSTUVWXYZ) 
(DIGIT  0123156789) 

(MARK  :,;(){]* *1$) 

(OTHERCHARACTER  !) 

( LETTER/ A: V  ABCDEFGHI  JKLMNOPQRSTUV) 
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Moreover,  a  program  that  does  nothing  but  accept  a  number  and  then  print 
it  will  usually  accept,  say,  3-1415926535897932,  and  then  print  some 
truncated  or  rounded  value  such  as  3-1415927. 

Tne  semantics  of  1/0  conversion  can  be  cleanly  separated  from  the 
semantics  of  arithmetic  operations  by  insisting  that  all  program 
assertions  (and  theorems)  that  refer  to  named  program  variables, 
including  input  and  output  variables,  are  interpreted  as  statements 
about  actual  values  that  are  exactly  machine  representable.  By  taking 
this  viewpoint,  I/O  conversion  details  become  a  secondary  issue  that  can 
be  dealt  with  once  and  for  all  by  proving  properties  of  tne  conversion 
programs. 

Note  that  we  did  not  require  in  the  above  Interpretation  that 
literal  constants  appearing  in  assertions  be  machine  representable.  It 
might  be  pe-fectly  correct  to  assert  that 

x  ♦  y  <  0. 1 

even  though  0.1  is  not  machine  representable.  On  the  other  hand,  an 
assertion  that 

x  ♦  y  s  0.  1 

sight  make  mathematical  sense  in  the  context  of  the  real  domain  but  not 
be  true  of  any  pair  of  values  in  the  machine  representable  domain  of 
floating-point  numbers  (henceforth  called  R).  For  the  latter  assertion 
to  make  sense  in  most  contexts,  one  would  instead  write 

x  ♦  y  x  Rep(0.  1) 

where  Rep(v)  is  a  function  that  returns  the  unique  value  contained  In 
the  domain  R  that  is  "closest"  to  the  real  value  v.  One  would  hope  that 
an  input  device  accepting  a  value  (say,  z)  for  input  to  e  program  would 
set  the  actual  value  of  z  to  Rep( input)  but  one  cannot  be  sure  that  this 
will  occur  because  the  semantics  of  J73/1  do  not  apply  to  1/0  devioes. 
A  precise  definition  of  Rep(v)  will  be  given  in  Section  3  of  this 
appendix . 


2.  Chooalna  an  Abstract 


Ian  A 


In  selecting  a  aathaaat ically  olaan  abstract  representation  for 
aachlna  nuabers  and  arlthaetlo  we  are  necessarily  Influenced  by  wnat 
actual  lapleaen tat  ions  of  J73/I  do  (or  should  do  according  to  the 
lnforaal  seaantlos).  In  particular,  nuabers  are  of  a  few  fixed  lengths, 
have  fixed  size  ranges,  and  are  aanlpulated  by  hardware  arlthaetlo  units 
that  have  *iat  we  alght  call  "custoaary  lapleaen tat  Ions" .  The 
capabilities  of  the  hardware  In  effect  deteralne  the  seaantlos  of  aost 
of  the  arlthaetlo  operations.  We  want  to  aodel  what  a  good  custoaary 
lapleaentatlon  should  do  rather  than  cater  to  a  variety  of  possible 
ldiosyncraclea  that  alght  occur  In  a  poor  lapleaentatlon  of  arlthaetlo 
on  soae  particular  aachlne. 

A  possible  representation  of  nuabers  In  R  would  be  an  indexed  array 
of  digits  where  each  digit  d  satisfies  0  <«  d  <  b  (where  b  Is  the  maiber 
base  of  the  lapleaentatlon),  and  the  exponent  aultlpller  Is  deteralned 
by  the  aaallest  Index  value  for  wnich  an  array  value  Is  nonzero,  for 

exaaple,  the  octal  ntaiber  2.35  x  8"^  alght  be  represented  by  an  array  A 
where  Al-6]  >  2,  A[-5]  >  3,  A[-4]  ■  5,  and  all  other  values  of  the  array 
are  zero.  One  could  then  desorlbe  all  of  the  effects  of  arlthaetlo 
stateaents  In  a  prograa  In  teras  of  exact  Integer  arlthaetlo  on  arrays. 
This  approach  has  soae  attractive  features  but  would  probably  produce 
too  auch  low-level  detail  to  be  handled  effectively  In  the  verification 
systea . 

Another  way  to  proceed  (which  Is  closer  to  the  custoaary 
lapleaentatlons)  Is  to  represent  a  nuaber  v  In  R  by  a  pair  of  Integers 
(n.e)  such  that 


v  t  n  •  b* 

where  b,  (b  >  1)  Is  the  Integer  base  of  the  nuaber  systea.  With  this 
representation  the  nuabers  in  R  fora  an  algebraio  ring,  so  that  if  u  and 
v  are  in  R,  then  the  values  u*v,  u-v,  u*v,  -v,  abs(v)  are  also  In  R. 
Moreover,  arlthaetlo  using  these  operators  Is  associative  and 
distributive. 
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Unfortunately,  tne  finite  size  of  aachlne  representations  1 eposes 
additional  restrictions  of  the  fora: 

N 1  <«  n  <>  N 2 
11  <•  e  <i  E2  . 


With  these  restrictions  on  size  of  n  and  e,  none  of  the  aatheaat lcally 
exact  operations  u*v,  u-v,  u*v,  -v,  sbs(v)  necessarily  produce  nuabers 
contained  In  R.  With  u  *  (nl.el),  v  *  (n 2,e2),  and  u.v  both  in  R,  the 
product  u*v  given  exactly  by 


( nl 


•  n2)  •  b 


(eUe2) 


can  fall  to  Beet  either  or  both  of  the  above  constraints.  If  the 
constraint  on  size  of  (eWe2)  is  violated  (exponent  over/imderflow) , 
then  there  Is  no  value  In  R  that  Is  "close"  to  u*v,  and  Rep(u*v)  does 
not  exist.  By  "close”,  we  seen  the  following: 

Let  z  «  (n.e)  «  n  •  b®  In  the  doesln  of  unrestricted  n  and  e.  Then 
there  Is  a  value  In  R  that  Is  close  to  z  If  there  exists  any  pair  of 
values  zl  and  z2,  both  In  R  such  that 

zl  <*  z  <>  z2  . 

Moreover,  in  this  case  there  will  exist  two  values  yl  and  y2,  both  In  R 
such  that: 


(1)  Zl  <«  yl  <*  z  <a  y2  <«  z2. 

(2)  There  exists  no  value  w  in  R  such  that  yl  <  w  <  y 2. 


One  of  tne  values  yl,  y 2  Is  the  closest  value  to  z  In  R.  Condition 
(2)  above  aerely  states  that  In  a  total  ordering  of  the  values  in  R 
there  is  a  closed  interval  defined  by  soee  pair  of  consecutive  values 
that  contains  the  value  z. 


Not*  that  we  have  not  required  a  uni  qua  rapraaantatlon  of  tha 
valuta  In  R.  (kilquanaaa  of  rapraaantatlon  will  turn  out  to  have  no 
partloular  slgnlfloanoe  or  laportanoa  with  raapaot  to  proportion  of  tha 
ahatraot  aodel. 


To  llluatrata  tha  general  faaturaa  of  a  doaaln  R  basad  on  tha  above 
rapraaantatlon  aoheae,  oonaldar  tha  partloular  oaaa  of  a  signed  four- 
dec  laal -digit  "mantissa"  with  a  slgnad  two-daclaal -digit  exponent .  We 
than  hava  b  *  10  and 


Tna  nuabar  123  can  be  exactly  represented  in  two  ways— a. g 


Tha  nuabar  pi  *  3-1*159265...  Is  not  In  R,  but  ws  hava  that 


where  no  valua  In  R  lias  between  yi  and  y 2.  The  oloaaat  value  to  pi  Is 
In  faot  y2,  and  this  valua  happens  to  hava  a  unique  rapraaantatlon  in  R, 
although  this  property  will  not  hold  in  general. 


In  all  of  the  following  discussion  wa  will  as suae  that  reals  are 
Internally  re pro sen tad  by  a  slgnad  Integer  consisting  of  at  aost  t 
digits  of  a  fixed  base  b,  associated  with  a  Integer  exponent  a  such  that 


Exoept  for  the  seaantlca  of  ovar/underflow  It  will  not  be  necessary 
to  oonsldar  tha  internal  representation  of  exponents.  Exponents  could, 
for  exaaple,  be  soaled  to  be  all  non-nagatlva.  The  values  in  R  are  the 
exact  values  of  tha  fora: 


where 


n  •  b 
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(bl-  1)  <»  n  <«  bfc-  1  . 


This  differs  froa  cuatoaary  lapleaen tat  tons  only  In  the  detail  that  the 
above  bounds  on  n  assure  that  If  v  Is  In  I),  then  so  Is  -v.  This  is  not 
necessarily  true  In  soae  aachlnes — e.g. ,  those  uaing  one  fora  of  twos- 
coapleaent  arlthaetlc  where  the  single  aost-negat lve  aachlne  nuaber  has 
no  positive  inverse. 

In  the  following  section  we  define  soae  funotlons  of  arbitrary  real 
arguments  to  be  used  as  a  basis  set  for  descrlMng  precisely  the  results 
to  be  expected  froa  arlthaetlc  operations  _arrl<-l  out  on  values  In  the 
doaain  R. 

3-  PcfialUgaa 

It  will  be  useful  to  define  the  following  functions  of  a  real 
arguaent  x,  recalling  that  b  Is  the  base  of  the  nuaber  systea  and  t  Is 
the  "wordlength" .  First,  the  functions  Sign,  Floor,  and  Celling  t»ve 
the  usual  seanlngs.  That  is. 


Stgn(x)  *  if  x  *  0  then  0  else  x/tos(x) 
Floor(x)  ■  largest  Integer  <*  x 
Ceillng(x)  a  saallest  integer  >■  x  . 


Next,  we  give  three  coapletely  equivalent  definitions  or  a  function 
Sp(x)  tfiich  aay  be  used  Interchangably .  Depending  on  prograa  context, 
one  definition  alght  be  aore  natural  or  useful  than  another. 

(1)  Ep(x)  a  if  x  a  o  then  0  else  the  unique  integer  p  such  that 

b1*1  <a  Abs(x)  •  bp  <  bfc 


(2)  Ep(x)  a  if  x  a  o  then  0 

else  Celllng(t  -  1  -  Log&( Abs(x))) 
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elalf  Aba(x)  <  6  and  Abs(x)  >■  b 


•lair  Abs(x)  >  b  than  Ep(x/b)  -  1 


We  also  need  tna  fol lowing  three  functions  derived  froa  Ep(x) 


Lo(x)  *  Slgn(x)  •  Floor(Abs(x)  •  Bp(x))  /  Bp(x) 


Aaong  the  above  functions,  Bp(x)  effectively  returns  the  nuaber  of 
"shifts"  necessary  to  1  eft-noraal  1  se  a  value  of  the  Internal 
representation.  The  function  Bp(x)  Is  the  Integer  multiplier  necessary 
to  acooapllsh  the  shift.  Lo(x)  Is  the  largest  value  In  R  that  Is  <•  x, 
and  Hl(x)  la  the  aaallest  value  In  R  that  Is  >  x.  Note  that  the 
definition  of  Hl(x)  requires  no  special  handling  of  the  oase  where  the 
next  valus  In  R  after  x  requires  Incrsaaitatlon  of  the  exponent  (occurs 
only  *>en  all  of  the  digits  of  Lo(x)  are  equal  to  b-l). 


Ignoring  for  the  aoaent  the  possibility  of  exponent  over/wderflow, 
one  oan  finally  define  the  function  Rep(x)  as: 


This  is  the  previously  proalsed  function  that  provides  the  closest 
value  in  R  to  an  arbitrary  real  x.  It  Is  this  function  that  should  be 
applied  to  values  froa  an  Input  devioe  to  obtain  the  correct  Internal 
representation. 


4.  Axiomatixation  a x  ArUnaftfcU 


The  function  Rep(x)  derived  In  the  previous  section  prescribes  sn 
unambiguous  set hod  of  obtaining  a  "correctly"  rounded  t-slgnlf leant 
digit  representation  of  a  real  value.  Most  good  nachlne  implementations 
of  arithmetic  that  use  double-length  registers  in  the  computation  of  an 
arithmetic  function  of  two  arguments  either  round  correctly  or  are 
capable  of  doing  so.  If  one  decides  that  the  J73/I  semantics  of 
arithmetic  imply  that  correct  rounding  always  occurs,  then  the  following 
equalities  are  always  exact.  With  u.v  in  R, 


Result  of: 
Result  of: 
Result  of: 
Result  of: 
Result  of: 
Result  of: 


Aos(u)  s  Sign(u)  *  u 
-  u  «  (-1 )  •  u 
u  ♦  v  s  Rep(u  ♦  v) 

u  -  v  »  Rep(u  -  v) 

u  •  v  «  Rep(u  •  v) 

u  /  v  »  Rep(u  /  v) 


Por  example,  after  the  J73/I  assignment  stateamt 
11  s  (AA  ♦  BB)  •  CC; 
the  exact  value  of  21  is  given  by 

Rep( Rep( AA  ♦  BB)  *  CC]. 


Recall  that  Rep  is  a  function  that  maps  arbitrary  reals  into 
numbers  in  the  range  R.  Since  actual  implementations  limit  the  site  of 
the  exponent  used  in  the  internal  representation,  therm  will  be  oases 
where  the  result  of  an  Input  operation  or  an  arithmetic  operation 
produces  a  maber  with  no  close  representation  as  defined  in  Section  2 
of  this  appendix.  The  actual  semantics  of  operations  involving  numbers 
outside  the  range  R  has  in  the  past  depended  on  programming  language 
conventions  and  implementation  details.  Fairly  frequent  use  has  been 
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Md«  or  tit*  convent  Ion  that  a  number  too  aaall  to  ha  represented  with  a 
negative  exponent  in  the  la  plea on ted  range  Is  converted  to  aero,  while 
nuabers  too  large  to  be  represented  are  converted  to  the  largest 
aaohlne-representable  number.  These  conversions  aay  or  aay  not  be 
aoooapanled  by  run-tlae  error  aessages.  Neither  of  the  above  conversion 
rules  Is  particularly  satisfactory  froa  the  standpoint  of  arlttaetle 
axloaat last  Ion  or,  for  that  aatter,  actual  coaputatlonal  utility. 

A  auch  cleaner  solution  Is  to  Insist  that  If  a  value  z  has  no  close 
representation  In  R,  then  Its  value  is  undefined.  Moreover,  any 
arlthaetlc  operation  taking  z  as  an  arguaent  returns  the  undefined 
value.  To  Incorporate  this  rule  In  the  above  axloaatlzatlon  of 
arlthaetlc  it  Is  only  necessary  to  redefine  the  function  Rep  as  follows. 
Let : 

Sail  lest  ■  (Tne  sail  lest  positive  non-zero  number  In  R) 

Largest  *  (The  largest  positive  maber  In  R) 

Rep*(x)  •  If  Aos(x)  >  Largest  or  Abs(x)  <  Smallest 
then  undefined  else  Rep(x) 


Replacing  Rep(x)  by  Rep*(x)  In  each  of  the  axioms  listed 
above— that  is, 


Result  of:  u  ♦  v  *  Rep*(u  ♦  v) 


—ensures  that  all  arlthaetlc  operations  are  well  defined  for  all 
arguaents  and  produce  either  a  unique  value  In  R  or  the  undefined  value. 


5.  Error  Bounds 

For  ••oh  program  statement  that  oarrlas  out  on*  or  more  arithmetic 
operations  It  is  possible  to  state  (assert)  bounds  on  either  the  real 
value  produced  or  Its  representation  in  B.  For  example,  if  u,  v  and  x 
•re  to  be  Interpreted  as  real  values  In  a  program  oontext,  then  a 
prograa  Identifier— say ,  UU — associated  with  the  value  of  u  will  have  as 
an  actual  value  either  Lo(u)  or  Hl(u).  Therefore  a  statement  such  as 

XX  s  UU  ♦  VV; 

will  have  the  effect  that  the  actual  value  of  XX  satisfies  the 
inequal itles 

Rep[Lo(u)  ♦  Lo(v)]  <«  XX  <»  Rep(Hl(u)  ♦  Hl(v)]  . 

There  is  a  sizable  literature  on  the  analysis  of  algorithms,  using 
some  form  of  error  bounding  mechanism  similar  to  the  above.  Whether  or 
not  this  technique  can  be  useful  In  proving  nontrivial  properties  of 
programs  using  substantial  amounts  of  real  arithmetic  Is  a  matter  for 
future  study  and  experimentation. 
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